UNABLE TO GET IDLE TO RUN

Peter Otten __peter__ at web.de
Mon Oct 26 09:55:46 EDT 2015


Terry Reedy wrote:

> On 10/23/2015 5:42 AM, Peter Otten wrote:
>> Laura Creighton wrote:
>>
>>> In a message of Fri, 23 Oct 2015 00:19:42 -0400, Terry Reedy writes:
>>>> On 10/21/2015 11:24 AM, Terry Alexander via Python-list wrote:
>>>>
>>>>> I have tried installing both Python 2.7 and 3.5, and in both cases I
>>>>> cannot get IDLE to work. I received the following message both times:
>>>>
>>>> What OS? Windows? which version?  How did you start IDLE?  Start menu
>>>> icon?  Command line?
>>>>
>>>>> IDLE’s subprocess didn’t make connection.Either IDLE can’t start a
>>>>> subprocess or personal firewall software is blocking the connection.
>>>>>
>>>>> I am running Norton, and disabled it, but still IDLE will not run. Any
>>>>> suggestions?
>>>>
>>>> Don't shout with ALL CAPS in the subject line.  It usually indicates
>>>> spam.  I already know that this problem is very frustrating.
>>>>
>>>> Firewalls are seldom the problems anymore.  I occasionally saw this on
>>>> Win 7 when restarting, but never on startup, and never more than once
>>>> or twice in a session.
>>>>
>>>> What's left is misconfiguration of your network interface that prevents
>>>> a loopback connection.  There might be answers on Stackoverflow that
>>>> would help, depending on your OS.
>>>>
>>>> In the meanwhile, you can start IDLE with the -n option.  Either use a
>>>> command line or create an 'IDLE -n' icon.  Again, details depend on
>>>> exact OS.
>>>> Terry Jan Reedy
>>>
>>> You can also get this message if you run idle in directory where you
>>> have your own python file whose name shadows something in the
>>> standard library (that idle is interested in).  I think it was
>>> a file named 'string.py' that did this to a student of mine a
>>> few years ago.
>>> Laura
> 
> I can imagine that a bad socket module might have this effect.  With
> verification that a user file could have this effect, I would augment
> the message.
> 
>> I tried it out:
>>
>> $ mkdir test
>> $ cd test
>> $ touch string.py
>> $ idle3
>> Traceback (most recent call last):
>>    File "<string>", line 1, in <module>
>>    File "/usr/lib/python3.4/idlelib/run.py", line 12, in <module>
>>      from idlelib import CallTips
>>    File "/usr/lib/python3.4/idlelib/CallTips.py", line 16, in <module>
>>      from idlelib.HyperParser import HyperParser
>>    File "/usr/lib/python3.4/idlelib/HyperParser.py", line 14, in <module>
>>      _ASCII_ID_CHARS = frozenset(string.ascii_letters + string.digits +
>>      "_")
>> AttributeError: 'module' object has no attribute 'ascii_letters'
>>
>> Then idle shows the message and quits after you hit OK.
>>
>> Is there a bug report?
> 
> No.  Quitting because a stdlib module cannot be imported (or corrupted)
> is not a bug.  AttributeError is a typical symptom.  A user file called
> random.py is probably more common.

The "bug" or misfeature is that idle automatically adds the working 
directory to sys.path. Ideally the editor should see the unaltered path 
while scripts started from within idle might be allowed to import from the 
working directory.





More information about the Python-list mailing list