Linux (Manjaro) inferring QML type from a .py file

Question

First of all, this is my first post, so I hope I'm following the proper guidelines and am stating the issue clearly.

I'm personally not too Linux-savvy, only using it to do some code on occasion, though I do most of that in Windows. To be more precise, I've run into the following issue while running Manjaro on a virtual machine.

Today, while using the PyQt5 library, I noticed a small annoyance. In general, Linux assumes all files ending with .py are python scripts. However, if I happen to have some code which imports PyQt AND has any sort of { brackets, then Manjaro immediately lists it as a "Qt Markup Language" file. Here's some dummy code that replicates the issue saved as "test.py"

#!/usr/bin/env python3
from PyQt5 import QtWidgets
some_dict = {}

Adding the shebang didn't do much. If I erase either the second OR the third line, the OS says its file type is "Python script", but if I keep both, then it infers it as a QML (Qt Markup Language file), because of the brackets (I assume). This also happens if I format strings with f'' or with .format(), so I know it's not just a dictionary issue.

This has no impact whatsoever on my code, but I still find it mildly annoying and I'd like to know how:

1. Linux infers file types since it doesn't care much for extentions
2. How I can change this if there's a quick solution

Like I said, this is no big deal, especially since I do my editing using the terminal, but it bothers me and makes me curious. Thanks for your help and have a great day!

UPDATE 1: I browsed the wiki and found this: https://wiki.archlinux.org/index.php/XDG_MIME_Applications#mimeapps.list

I can successfully replicate their example, but so far am having issues adapting this to .py files. Even after I set the new rules, it seems to still browse the configuration files in /usr/share/mime.

UPDATE 2: I'm still unable to write rules that successfully override what's considered a QML when the extention is .py. However, if I replace the import statement with

import PyQt5.QtWidgets as QtWidgets

then I'm able to "trick" the rules and it now successfully labels it as a "Python Script file". The "issue" itself wasn't solved, but I actually learned a lot from this.

Answer 1

In general, Linux assumes all files ending with .py are python scripts

Linux as the kernel doesn't really care about file endings. It only checks whether a file starts with a shebang or some magic number such as 0x7F followed by ELF(45 4c 46) for ELF.

I can reproduce this issue with 1.8.14 (Xfce 4.12) on Slackware 64 -current. Thunar does not infer file types by itself but uses a MIME database that other programs use as well:

$ grep mime /proc/$(ps -C thunar -o pid:1=)/maps
7f2c3a709000-7f2c3a730000 r--s 00000000 08:01 1055508                    /usr/share/mime/mime.cache

You can use xdg-mime query filetype or a Perl program called mimetype from perl-file-mimeinfo to check a MIME type for a given file:

$ mimetype test.py
test.py: text/x-qml

And use -D with mimetype to check why was the given MIME type chosen:

$ mimetype -D test.py
> Data dirs are: /home/ja/.local/share, /usr/local/share, /usr/share
> Checking inode type
> Value "import Qt" at offset 3044 matches at /usr/share/mime/magic line 120
>> Value "{" at offset 3065 matches at /usr/share/mime/magic line 121
test.py: text/x-qml

As you see, in this case mimetype says that test.py is text/x-qml because it contains import Qt and curly braces. If test.py looked like that:

#!/usr/bin/env python3

from PyQt5 import QtWidgets

mimetype reports it's a Python script because even though it can find import Qt there are no curly braces:

$ mimetype -D test.py
> Data dirs are: /home/ja/.local/share, /usr/local/share, /usr/share
> Checking inode type
> Value "import Qt" at offset 3044 matches at /usr/share/mime/magic line 120
> Failed nested rules
> Checking globs for basename 'test.py'
> Checking for extension '.py'
test.py: text/x-python

What's funny, if test.py is renamed to test.pl then mimetype claims it's Perl script.

OTOH, file says it's a Python script even after renaming it:

$ file test.pl
test.py: Python script, ASCII text executable

See this answer to read about discrepancies between mimetype and file: 'file --mime-type' and 'mimetype' Commands Returning Different Results.