New submission from Mark Roseman:
When we create e.g. string.py that shadows a stdlib module needed by IDLE, it
would be nice if a better error message could be shown, pointing to that cause.
Original message:
lac at smartwheels:~/junk$ echo "print ('hello there')" >string.py
lac at smartwheels:~/junk$ idle-python3.5
hello there
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.5/idlelib/run.py", line 10, in <module>
from idlelib import CallTips
File "/usr/lib/python3.5/idlelib/CallTips.py", line 16, in <module>
from idlelib.HyperParser import HyperParser
File "/usr/lib/python3.5/idlelib/HyperParser.py", line 14, in <module>
_ASCII_ID_CHARS = frozenset(string.ascii_letters + string.digits + "_")
AttributeError: module 'string' has no attribute 'ascii_letters'
IDLE then produces a popup that says:
IDLE's subprocess didn't make connection. Either IDLE can't stat a subprocess
por personal firewall software is blocking the connection. <ok>
--------
I think that life would be a whole lot easier for people if instead we got
a message:
Warning: local file /u/lac/junk/string.py shadows module named string in the
Standard Library
I think that it is python exec that would have to do this -- though of
course the popup could also warn about shadowing in general, instead of
sending people on wild goose chases over their firewalls.
----------------------
Laura, I think what you want should actually be more-or-less doable in IDLE.
The main routine that starts IDLE should be able to detect if it starts
correctly (something unlikely to happen if a significant stdlib module is
shadowed), watch for an attribute error of that form and try to determine if
shadowing is the cause, and if so, reissue a saner error message.
The subprocess/firewall error is occurring because the ‘string’ problem in your
example isn’t being hit right away so a few startup things already are
happening. The point where we’re showing that error (as a result of a timeout)
should be able to check as per the above that IDLE was able to start alright,
and if not, change or ignore the timeout error.
There’ll probably be some cases (depending on exactly what gets shadowed) that
may be difficult to get to work, but it should be able to handle most things.
See full thread starting at
https://mail.python.org/pipermail/python-dev/2015-October/142061.html
----------
components: IDLE
messages: 253693
nosy: kbk, markroseman, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: better startup error messages in IDLE when stdlib modules shadowed
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25514>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
