Repository navigation
IDLE: Detect Python files even if name doesn't end in .py #51053
Description
| BPO | 6804 |
|---|---|
| Nosy | @terryjreedy, @amauryfa, @serwy |
| Files |
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']Metadata
Metadata
Assignees
Projects
- Status
Activity
ggenellina commentedon Aug 29, 2009
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 commentedon Sep 8, 2009
This makes sense, but the code should:
ggenellina commentedon Nov 14, 2009
This new patch addresses the previous comments.
terryjreedy commentedon Aug 7, 2010
I am a little puzzled by this issue.
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 commentedon Jul 16, 2012
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 commentedon Jul 16, 2012
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 commentedon Jul 17, 2012
Is the error message a traceback? If so, could you open a separate issue for it?
weirdink13 commentedon Jul 22, 2012
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 commentedon Oct 3, 2014
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.
devdanzin commentedon Sep 22, 2025
This issue doesn't include recognizing the Python shebang, only fetching matching extensions from Windows registry, which doesn't seem useful as per previous messages. A better way to handle files with other extensions is proposed in #51107. I suggest this one to be closed.