Created on 2008-01-06 12:47 by richjtd, last changed 2010-09-23 13:46 by Stephan.Bellegy. This issue is now closed.!
What's your OS and how did you install Python on your machine?
I'm on 32-bit Windows Vista, and I installed with the Python 2.5 msi.
Please open IDLE from the command line:
1. start cmd.exe
2. run "<path to python.exe>" "<path to python>/Lib/idle/idle.py"
That should give you an error, please report it.
I have the exact same problem also running 32-bit vista.
Idle worked the first time I started it but after that it doesn't start.
I did run the command and got this error.
C:\Users\Joakim>"C:\Python25\python.exe" "C:\Python25\Lib\idle.py"
C:\Python25\python.exe: can't open file 'C:\Python25\Lib\idle.py':
[Errno 2] No such file or directory
I also not able to start the interpreter from cmd using the python
command. I've looked around a bit and read something about adding to
PATH. Haven't tried that because the guide wasn't written for Vista.
Noticed I missed a bit of the path but it didn't matter.
Changed the path to C:\Python25\Lib\idlelib\idle.py and got another
error.
C:\Users\Joakim>"C:\Python25\python.exe" "C:\Python25
\Lib\idlelib\idle.py"
Traceback (most recent call last):
File "C:\Python25:\\Users\\Joakim\\.idlerc\\recent-files
.lst'
There should be a edit button somewhere but I couldn't find it, so I
had to post a new entry.
Can you access the file C:\\Users\\Joakim\\.idlerc\\recent-files.lst
with the explorer? Do the directory and the file exist?
I can access the file. I renamed the file and tried the command again.
Then I started IDLE and got a window. A new recent-files.lst was
created. So I guess I solved the problem temporarily.
It smells like a Vista issue.
But IDLE shouldn't crash w/o a notice if the recent list can't be opened.
I've been away for a couple of days, but can replicate everything
Joakim has reported in my abscence. Deleting/renaming recent-files.lst
allows me to launch IDLE (from cmd or Start Menu).
Oddly though, if I close IDLE, copy/paste the contents of the old
recent-files into the new one, and then restart IDLE, it still works.
Another thing I noticed, after launching IDLE from the Command Prompt,
is that I get this error (while IDLE is still running and I haven't
done anything with it yet):
Traceback (most recent call last): File "[...]\idlelib\run.py", line
82, in main exit()
File "[...]\idlelib\run.py", line 208, in exit del sys.exitfunc
AttributeError: exitfunc
Is that normal?
Can anybody provide a complete, reproducible procedure for that bug
(rather than reproducible procedures to work around it)? Such a
procedure might have to start with installing Python.
I can't get it to do it again. Unless someone else is still
experiencing the problem, perhaps it was fixed (deliberately or
otherwise) by this month's Vista hotfixes that came down automatically
a couple of days ago.
Thanks for your help everyone.
1. Could you look at the properties of the .idlerc\recent-files.lst that you
saved and compare them to the new file which worked? In particular, what
about access permissions?
2. I agree that IDLE should have a better error response if opening a user
config file fails.
Aha! There is no difference in Permissions, but the working recent-
files file isn't "hidden" but the one generated originally by IDLE was.
If I make the one I made "hidden" then IDLE stops working again.
The .idlerc folder has been hidden all along though - that doesn't
affect it.
If anyone's changing the way IDLE writes these files, would it be worth
me saying that aesthetically, I'm not a fan of it putting them in a
hidden folder in my top level User folder. What about putting them down
inside Users/AppData like other applications do? Just a thought..
I've studied the problem with Process Monitor. If a file is hidden,
open(f, "w") fails, whereas os.open(f, os.W_OK|os.O_CREAT) succeeds.
In the succeeding call, process monitor reports
Desired Access: Generic Read/Write
Disposition: OpenIf
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read, Write
AllocationSize: 0
OpenResult: Opened
In the failing call, it reports
Desired Access: Generic Write, Read Attributes
Disposition: OverwriteIf
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read, Write
AllocationSize: 0
I then tried os.open(f, os.W_OK|os.CREAT|os.O_TRUNC) which also fails,
giving
Desired Access: Generic Read/Write
Disposition: OverwriteIf
Options: Synchronous IO Non-Alert, Non-Directory File
Attributes: N
ShareMode: Read, Write
AllocationSize: 0
So it fails for FILE_OVERWRITE_IF, but succeeds for FILE_OPEN_IF. These
map back to CREATE_ALWAYS and OPEN_ALWAYS - apparently, you can't
truncate a hidden file on Vista.
As a follow-up, it appears that Windows didn't allow truncating hidden
or system files since Windows 2000. If you change the flags on .idlerc
to hidden in (say) W2k3, IDLE will also fail to start - so it's not a
Vista issue.
The question is why the folder "sudenly" became hidden - Python has no
API to make it so.
In any case, the proper solution is to delete the file rather than
overwriting it, perhaps like so
def save_overwrite_open(fname):
try:
return open(fname,"w")
except IOError:
os.unlink(fname)
return open(fname,"w")
Thanks for the fix. r60225.
backported 2.5.2c1
I also had the same problem in Windows 7 64 bit. I unhid the file and
everything works now
Reproduced today with Python 2.6.6 and 2.7 on Win7 32 bits.
Deleting .idlerc directory made it.
Doesn't look like fixed guys ! ;-)
Please submit this as a new bug issue, preferably with precise instructions on how to reproduce it. Can you provide some clue how the file became hidden in the first place?
New bug reported here