IDLE does not recognize '.py' as a python file

[Mm12345678910]

Bug report

Bug description:

when I just wrote this program, and just save it with name .py, the highlight does not work.

p=1
t=1
while 1:
    p*=0.95
    t+=1
    print(p,t)

But, when I just rename it with 1.py, the highlight works.

I'm using Windows 11, Python 3.13.0b4.

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[ZeroIntensity]

cc @terryjreedy

[terryjreedy]

@ZeroIntensity I get notified when topic-IDLE is added. (I forget how one signs up for label notifications.)

[terryjreedy]

IDLE does not see '.py' as a python file because os.path.splitext('.py') returns ('.py', '') rather than `('', '.py'). This is intentional: "Leading periods of the last component of the path are considered to be part of the root:" (with examples equivalent to the result above). I am not sure whether to 'fix' IDLE or close this as "Don't do name files this way."

[terryjreedy]

I am seeking other coredev opinions. If 'fix', I will open a PR augmenting the condition on editor.py line 810, os.path.normcase(ext) in py_extensions with or (ext == '' and os.path.normcase(base) in py_extensions).

[serhiy-storchaka]

Files like '.py' are considered not having extension on Unix. Windows Explorer usually removes the '.py' suffix when showing other file names, but not in this case. So I think that the solution is -- "Don't do that".

[ZeroIntensity]

@ZeroIntensity I get notified when topic-IDLE is added. (I forget how one signs up for label notifications.)

Oh, good to know!

[skirpichev]

Files like '.py' are considered not having extension on Unix.

I would say, that "extension" is not a Unix concept at all. But hiding "."-prefixed filenames in ls (POSIX) and file managers - is.

Windows Explorer usually removes the '.py' suffix when showing other file names, but not in this case.

In Gnome Files different applications suggested for e.g. "a.py" (IDLE) an ".py" (text editor). (Probably this happens for Windows Explorer as well.) That's logical on the above ground ("." - signal to hide file, thus can't precede extension). In Windows, this treated differently, I guess, because ".py"-like filenames are invalid in DOS (only extension, no actual filename).

So, it's not something Windows-specific.

"Don't do that".

+1

[serhiy-storchaka]

The default extension is added by Tk. It is beyond our power to control how it works in such corner case. We can make the Python source detection consistent with this, but I do not think that we should. This is too special case and it can fail in other ways.

[terryjreedy]

IDLE already allows one to load and file that decodes to unicode without error and attempt to run it. I am convinced that one should not use extension names as file names and that I do not want to guarantee that such files will work in all IDLE operations the same as properly named files. Therefore, closing as "won't fix". Thanks to all the commenters.