IDLE: Detect Python files even if name doesn't end in .py

[ggenellina]

BPO	6804
Nosy	@terryjreedy, @amauryfa, @serwy
Files	EditorWindow.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2009-08-29.21:44:38.335>
labels = ['expert-IDLE', 'type-feature', '3.10']
title = "IDLE: Detect Python files even if name doesn't end in .py"
updated_at = <Date 2020-06-08.01:02:36.371>
user = 'https://bugs.python.org/ggenellina'

bugs.python.org fields:

activity = <Date 2020-06-08.01:02:36.371>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2009-08-29.21:44:38.335>
creator = 'ggenellina'
dependencies = []
files = ['15334']
hgrepos = []
issue_num = 6804
keywords = ['patch']
message_count = 9.0
messages = ['92071', '92412', '95259', '113184', '165561', '165658', '165668', '166169', '228305']
nosy_count = 5.0
nosy_names = ['terry.reedy', 'amaury.forgeotdarc', 'ggenellina', 'roger.serwy', 'weirdink13']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6804'
versions = ['Python 3.10']

[ggenellina]

A Python source file name doesn't necesarily end
in .py/.pyw; on Linux, scripts usually have no
extension but are recognized by its shebang line.
Windows uses file type associations: .py files are of
type Python.File, and .pyc files are Python.NoConFile.

This patch makes IDLE recognize as a Python source
(and colorize) any file of those types, regardless of
extension.

http://permalink.gmane.org/
gmane.comp.python.general/636011

[amauryfa]

This makes sense, but the code should:

• not make the query when the extension is empty
• catch the WindowsError raised when the extension is not in the registry.

[ggenellina]

This new patch addresses the previous comments.

[terryjreedy]

I am a little puzzled by this issue.

1. Why would a Windows user use any extention other than .py or .pyw, which IDLE opens fine. How many people do something senseless like hand-registering, say 'xiq', as a python file?
2. .pyc files are binary files and NOT source code files and cannot be opened by IDLE as it will attempt to decode them into text. So why the check for that?

Also, I believe there is another issue to add a 'Treat this as Python code' entry to one of the menus. This would cover the case of files without extensions and files that are not python files but happen (on a case-by-case basis) to have python code embedded within.

So I am thinking that this should be closed.

[serwy]

This is related to bpo-6858. I assume that the point of this issue is to enable syntax highlighting by relying on the Windows registry?

[weirdink13]

I am also somewhat puzzled by this issue.
The other day I was able to open some .txt files just to see if I could and they opened just fine.
Just now I tryed to open a .jpg file and I got an error message, but then again, why would someone save a python file as a jpeg image?

[serwy]

Is the error message a traceback? If so, could you open a separate issue for it?

[weirdink13]

No. When I try to open the file a small window entitled "Specify file encoding" pops up that says
"The file's encoding is invalid in Python 3.x.
Idle will convert it to UTF-8.
What is the current encoding of the file?"
followed by an entry widget that has "cp1252" and "ok" and "cancel" buttons. When I click "ok" the computer go "dunnn" and a error window titled "Decoding Error" that says "File C:\Python32\misc\bee.jpg Failed to Decode" with an "ok" button which, when clicked, closes idle (the edit window, not the shell). Does that answer your question?

[terryjreedy]

bpo-6858 was the issue I referred to.
Recognizing #!...python, common on *nex, which the patch does not do, seems sensible. I thought about coding line, but general idea is not specific to python.