Not sure if I am posting in the right place, but I am having problems getting my python GIS programs to work on Windows 7 64 bit. These programs worked on XP 32 bit. I've done a lot of research and tried changing my PythonPath, moving the lib folder, etc and other suggestions. I made a new key in the registry under Python26 as suggested by another with the contents of the Desktop10.pth file. However I am still getting the same error posted below. I am currently running ArcGIS 10.0. I am probably missing something simple! Any help would be greatly appreciated! Thank you in advance.
Traceback (most recent call last):
File "Z:\Desktop\GISClimateMapping.py", line 85, in
import arcpy
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy__init__.py", line
17, in
from geoprocessing import gp
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing__in
it__.py", line 14, in
from _base import *
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 568, in
env = GPEnvironments(gp)
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 565, in GPEnvironments
return GPEnvironment(geoprocessor)
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 521, in init
self._refresh()
File "C:\Program Files (x86)\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing_bas
e.py", line 523, in _refresh
envset = (set(env for env in self._gp.listEnvironments()))
RuntimeError: NotInitialized
I had a very similar problem. We have a single licence which, if it's checked out to someone else, prohibits my script from running. I've found this empirically rather than through code/support but I'm fairly confident that's your issue.
You must use Python 2.6 32 bit with Arcgis 10.0, even with a 64 bit OS. I suspect (though not sure from the info provided) that you have another version of Python installed. I would first check to see how many versions are installed, and uninstall all of them except the one at C:\Pytho26\ArcGIS10.0. Then I'd install Python 2.6 (it's on the ArcGIS disk) at the location mentioned. You'll need to re-install numpy and matplotlib too, which are also on the disk. If that does not help, then I'd uninstall ArcGIS and every Python version on your machine, and then re-install ArcGIS. This sounds drastic, but ESRI's Python implementation is pretty sensitive, and you can waste days on trying to find an easy fix. This last step usually works.
I had this very error when the first line of my code was "import arcpy", and the solution for me was to insert a new first line to my python script: "import arcview".
My code was running fine on a system using ArcGIS 10.0, but ran into this problem after I upgraded my development box to 10.1 desktop and server. Various stackoverflow, gisstackexchange, and forums.arcgis.com articles pointed to PATH, PYTHONPATH, HLKM etc environment possibilities or checking your ArcGIS Administrator licensing. After reproducing the problem in both pyscripter and IDLE, confirming everything was as it should be with a properly uninstalled python 2.6, an installed python 2.7 environment, and a valid floating license the error still persisted. My best conjecture for why this fix worked is that perhaps starting with 10.1 arcgis license checkout may be more explicit.
For the record, I just encountered this problem in 10.1 while debugging an arcpy script in Visual Studio. It actually happened between runs with no code changes - one run worked, the next got the error. For whatever reason, adding the import arcview to the top worked. Maybe it is a license checkout issue, but such inconsistency is troubling.
Strange but true.
Had the same problem after upgrading ArcGIS (ArcInfo) 10.1 to 10.2.
Added one line in the python code:
import arcinfo
After this everything worked perfect. Easy to fix, hard to understand.
Thanks!
Willem
I think the problem was created by another user running ArcMap at the same time - since there is a single ArcGIS licence. When the user closed ArcMap in fact, the python script started running well.
This error might occur because your Python is 64-bit and your ArcMap 32-bit.
You can either update your python to a 64-bit version or update you ArcMap to a 64-bit.
How to get a 64-bit version of ArcMap:
From install. When you launch the autorun.exe application, the
startup window wil give you the option of installing ArcGIS Desktop
Background Geoprocessing (64-bit). This is only available in versions
10.1 and above
If you already have ArcGIS Installed in your computer. You can download a patch for the Background Geoprocessing (64-bit) here .
Related
I'm bundling a pygame app using py2app. The bundling works and the resulting bundle runs on my mac just fine. It also used to run on another person's mac just fine. However, recently I've started getting this error (from the console) when trying to run the bundle on his computer:
Traceback (most recent call last):
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 316, in <module>
_run()
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 311, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File "/Users/.../tmp/withconsole.app/Contents/Resources/withconsole.py", line 18, in <module>
pdb.set_trace()
File "bdb.pyc", line 53, in trace_dispatch
File "bdb.pyc", line 88, in dispatch_return
File "pdb.pyc", line 190, in user_return
File "pdb.pyc", line 210, in interaction
File "cmd.pyc", line 142, in cmdloop
File "pdb.pyc", line 279, in onecmd
File "cmd.pyc", line 218, in onecmd
File "pygame/macosx.pyc", line 10, in <module>
File "pygame/sdlmain_osx.pyc", line 14, in <module>
File "pygame/sdlmain_osx.pyc", line 10, in __load
ImportError: dlopen(/Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from: /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
Expected in: /usr/lib/libobjc.A.dylib
in /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
2013-11-09 06:19:50.794 withconsole[2797:1c03] ogclient Error
I even tried running an older bundle that used to work, yet now it no longer works! I'm 95% certain of that, anyway.
In any case, what's the issue and how can I fix it?
A standalone app from py2app creates its baked-in Python interpreter from whichever version of Python you use for py2app.
If you use, say, a Python built to run on any OS X 10.6 or later, the application (so long as it doesn't use any post-10.6 features) will also run on any OS X 10.6 or later. If you use a Python built to run on one particular 10.8 machine, the application will very likely not work on anything earlier than 10.8, and may not even work on other 10.8+ machines.
On top of that, if you're using any C extension modules that you built against C libraries that you built yourself, if those C libraries were built for your particular machine, they'll probably cause the same problem.
You built your Python interpreter with Homebrew. And maybe your SDL as well, which pygame depends on. And possibly other things. By default, Homebrew builds everything to run on your particular machine, not to be redistributable. Hence the problem.
To build an app that can run on 10.7 machines, you need to either build Python, SDL, etc. against the 10.7 SDK, or build it against a later API and specify -mmacosx-version-min=10.7. (There are a few other issues that can come up, but I'm pretty sure none of them affect CPython, so let's keep it simple.)
That will automatically set things up so any C extension modules you build use the same SDK and version settings, so you shouldn't have to worry about those. But you do have to worry about any C libraries you built that those extension modules depend on. For example, pygame links against libSDL, and if you built SDL for your local machine only, pygame isn't going to work on someone else's machine.
It's possible to get Homebrew to create SDK builds, but not always that easy. It's easier to just build Python manually and pass the right --configure flags. But it's even easier to take a binary that someone else has already built for portability and use that.
The official Python installers at python.org are built for 10.6+. The official SDL development libraries are built for 10.5+. Hopefully the same is true for other things you're depending on. If so, just brew uninstall (or, if you're wary and want to be able to undo this later, brew unlink) everything, run the binary installers, reinstall all the Python modules you need for the new Python, and py2app with it.
I wrote this all in general terms. From the output, it looks like the specific problem you're hitting on this particular run on your friend's particular 10.7 machine is that the SDL wrappers are depending on features of the ObjC runtime that didn't exist in 10.7. So, it's possible that just using a 10.7-friendly SDL, and your existing Python, would be sufficient. But I think you're better off using 10.7-friendly everything if at all possible.
If you're wondering what exactly the SDK does, the SDK Compatibility Guide in Apple's official docs explain the technical side of it pretty well, and there are a zillion blog posts like this one that explain the practical parts, but I'll try to summarize.
Each SDK is just a directory that has its own /usr/include, /usr/lib, /System/Library/Frameworks, and a few other things inside. When you build against an SDK, you end up compiling against its header files instead of your system's, and linking against its dylibs instead of your system's. This prevents you from using any new features added since 10.6 (with a nice compiler error, instead of a successful build that then won't start on half your users' machines). And it makes sure that, if you don't use any such new features, your program doesn't have load-time dependencies on anything that didn't exist in 10.6.
I am a newbie to Stack Overflow (first post), but really see the use of this website.
I'm stumped. We are trying to setup IIS 7.0 to run with WinPython 2.7 on a Windows 7 machine.
I am an IIS newb, but veteran Python user. IIS 7 can NOT find a library, which python finds, and executes, perfectly when ran on it's own. When executed via IIS, the script fails with a traceback, and IIS returns the 502.2.
I found this thread http://forums.iis.net/p/1209465/2073173.aspx?HTTP+Error+502+2+Bad+Gateway+Frustrations but the advised solution is simply another troubleshooting suggestion.
I found IIS's description (http://support.microsoft.com/kb/942057) of the error helpful, but futile.
I found Python's start-up options/parameters helpful (http://docs.python.org/2/using/cmdline.html), but futile.
I found IIS's advice for configuring Python helpful (http://support.microsoft.com/kb/276494, but (questionably?) incomplete.
This thread on manually defining an alternate bin folder (http://forums.asp.net/t/1303052.aspx?Tell+IIS+to+load+dll+from+another+directory+not+Bin+web+config+) might be where my solution lies, but I don't think it is because of the fact that this all worked on 2.6 without doing that to IIS.
IIS seems to allow python to import any module that is just a python script. As soon as it gets to a *.pyd (basically just python's version of a dll file) file, it screams. I'm no pro when it comes to DLLs and windows environments, but wouldn't IIS have to have paths to a bin folder of some kind? Do I have to manually edit them, as discussed in the last link above?
ACTUAL ERROR Details below for DLL failed Load:
The Error :
" HTTP Error 502.2 - Bad Gateway The specified CGI application
misbehaved by not returning a complete set of HTTP headers. The
headers it did return are "Traceback (most recent call last): File
"\estorage.equitable.int\riskmgmt\Quants\web\LinksPage.py", line 2,
in import pyweb File
"\estorage.equitable.int\riskmgmt\Quants\Common2014\Python\pyweb__init__.py",
line 5, in from core import * File
"\estorage.equitable.int\riskmgmt\Quants\Common2014\Python\pyweb\core.py",
line 2, in from pylib import pgdb File
"\estorage.equitable.int\riskmgmt\Quants\Common2014\Python\pylib\pgdb.py",
line 8, in from scikits import timeseries as ts File
"C:\WinPython-32bit-2.7.6.2-20140401\python-2.7.6\lib\site-packages\scikits.timeseries-0.91.3-py2.7-win32.egg\scikits\timeseries__init__.py",
line 13, in import const File
"C:\WinPython-32bit-2.7.6.2-20140401\python-2.7.6\lib\site-packages\scikits.timeseries-0.91.3-py2.7-win32.egg\scikits\timeseries\const.py",
line 79, in from cseries import freq_constants ImportError:
DLL load failed: The specified module could not be found. ".
I'm confident that the python environment is configured properly, as the script runs from the same executable (python.exe) via a command line. I'm thinking that I don't have IIS configured properly, for the new Python 2.7 install. The same script worked yesterday, on IIS and python 2.6. But during our upgrade from 2.6 to 2.7, a bunch of PATH and PYTHONPATH parameters all changed, plus we went from ActivePython to WinPython. WinPython is "registered" on the machine.
What I've tried
confirming python's sys.path is as expected at run-time in both IIS and command line - it is.
using the module from python command line.
recompiling the failing module using two different compilers (ming32 and VS2008).
putting duplicates of my new 2.7 modules in the old python26 folder.
pulling out lots of hair and other hacky stuff.
My next step, is to post this same message on a python forum. If anybody can advise on a good one for python-IIS related challenges, that would be appreciated.
Please help! Thanks in advance.
I got this 502.2 error when doing a clean installation of PHP 5.5 in Windows Server 2012 R2 with IIS 8.5.
It turns out PHP is a Visual C++ application which needs the library MSVCR110.dll in order to run properly. My computer does not have Visual Studio 2012 installed and thus it does not have this file. I got my problem solved by installing the Visual C++ Redistributable Packages https://www.microsoft.com/en-us/download/details.aspx?id=30679#
(Note: jc77 is my associate, and I'm actually the OP, as this was an x-post from IIS forums.)
We solved the problem.
tl,dr; portable python + sloppy/rookie compiling = strange behaviour + frustrations.
Bottom line, compile properly. For scikits.timeseries, using ming32 everything will walk, talk, and sound like it works in Spyder.exe, but not in python.exe. You have to use VS2008, if you want it to work in both.
More Info:
Winpython (as well as others) presents itself as identical to any other python installations, if you "register" the installation. It works great, 99% of the time. We learned the hard way, that "Winpython Interpreter.exe" and "python.exe" provided in the install are in fact different. Can't explain why, but the two executables gave different behavior. We were doing all our testing in Spyder, which must use "winpython interpreter.exe". The module which IIS couldn't find, would import and run no problem in Spyder. Then, in IIS, using python.exe, the module wouldn't import. We were operating on the assumption that the IDE would use python.exe, and that the stack was identical. As, 99% of the time, they appear to be. The way we were compiling scikits worked in winpython interpreter.exe. We were making a rookie mistake when compiling scikits, but it went un-noticed because it was working fine in our IDE (Spyder).
I'm adding these keywords for others : Anybody else who receives errors like this is likely using a portable python installation AND not compiling something properly. Winpython, Portable Python, eGenix, [and possibly?] Active State and Enthought Canopy.
While trying to configure CGI to run Perl in Windows 8.1, I had HTTP Error 502.2, but then I read loste's post and solved the problem. I had previously installed both Perl64 and Strawberry Perl. Although the IIS EventHandler pointed to only the Perl64 directory, both directories appeared in my Windows PATH variable. I prefer Strawberry Perl, so I changed the EventHandler to point to the Strawberry Perl directory and deleted the paths to Perl64 from the Windows PATH variable to solve the error.
Try this
print("Content-Type: text/html\n")
print("Hello Python World!")
You must specify the type of document
I'm bundling a pygame app using py2app. The bundling works and the resulting bundle runs on my mac just fine. It also used to run on another person's mac just fine. However, recently I've started getting this error (from the console) when trying to run the bundle on his computer:
Traceback (most recent call last):
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 316, in <module>
_run()
File "/Users/.../tmp/withconsole.app/Contents/Resources/__boot__.py", line 311, in _run
exec(compile(source, path, 'exec'), globals(), globals())
File "/Users/.../tmp/withconsole.app/Contents/Resources/withconsole.py", line 18, in <module>
pdb.set_trace()
File "bdb.pyc", line 53, in trace_dispatch
File "bdb.pyc", line 88, in dispatch_return
File "pdb.pyc", line 190, in user_return
File "pdb.pyc", line 210, in interaction
File "cmd.pyc", line 142, in cmdloop
File "pdb.pyc", line 279, in onecmd
File "cmd.pyc", line 218, in onecmd
File "pygame/macosx.pyc", line 10, in <module>
File "pygame/sdlmain_osx.pyc", line 14, in <module>
File "pygame/sdlmain_osx.pyc", line 10, in __load
ImportError: dlopen(/Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
Referenced from: /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
Expected in: /usr/lib/libobjc.A.dylib
in /Users/.../tmp/withconsole.app/Contents/Resources/lib/python2.7/lib-dynload/pygame/sdlmain_osx.so
2013-11-09 06:19:50.794 withconsole[2797:1c03] ogclient Error
I even tried running an older bundle that used to work, yet now it no longer works! I'm 95% certain of that, anyway.
In any case, what's the issue and how can I fix it?
A standalone app from py2app creates its baked-in Python interpreter from whichever version of Python you use for py2app.
If you use, say, a Python built to run on any OS X 10.6 or later, the application (so long as it doesn't use any post-10.6 features) will also run on any OS X 10.6 or later. If you use a Python built to run on one particular 10.8 machine, the application will very likely not work on anything earlier than 10.8, and may not even work on other 10.8+ machines.
On top of that, if you're using any C extension modules that you built against C libraries that you built yourself, if those C libraries were built for your particular machine, they'll probably cause the same problem.
You built your Python interpreter with Homebrew. And maybe your SDL as well, which pygame depends on. And possibly other things. By default, Homebrew builds everything to run on your particular machine, not to be redistributable. Hence the problem.
To build an app that can run on 10.7 machines, you need to either build Python, SDL, etc. against the 10.7 SDK, or build it against a later API and specify -mmacosx-version-min=10.7. (There are a few other issues that can come up, but I'm pretty sure none of them affect CPython, so let's keep it simple.)
That will automatically set things up so any C extension modules you build use the same SDK and version settings, so you shouldn't have to worry about those. But you do have to worry about any C libraries you built that those extension modules depend on. For example, pygame links against libSDL, and if you built SDL for your local machine only, pygame isn't going to work on someone else's machine.
It's possible to get Homebrew to create SDK builds, but not always that easy. It's easier to just build Python manually and pass the right --configure flags. But it's even easier to take a binary that someone else has already built for portability and use that.
The official Python installers at python.org are built for 10.6+. The official SDL development libraries are built for 10.5+. Hopefully the same is true for other things you're depending on. If so, just brew uninstall (or, if you're wary and want to be able to undo this later, brew unlink) everything, run the binary installers, reinstall all the Python modules you need for the new Python, and py2app with it.
I wrote this all in general terms. From the output, it looks like the specific problem you're hitting on this particular run on your friend's particular 10.7 machine is that the SDL wrappers are depending on features of the ObjC runtime that didn't exist in 10.7. So, it's possible that just using a 10.7-friendly SDL, and your existing Python, would be sufficient. But I think you're better off using 10.7-friendly everything if at all possible.
If you're wondering what exactly the SDK does, the SDK Compatibility Guide in Apple's official docs explain the technical side of it pretty well, and there are a zillion blog posts like this one that explain the practical parts, but I'll try to summarize.
Each SDK is just a directory that has its own /usr/include, /usr/lib, /System/Library/Frameworks, and a few other things inside. When you build against an SDK, you end up compiling against its header files instead of your system's, and linking against its dylibs instead of your system's. This prevents you from using any new features added since 10.6 (with a nice compiler error, instead of a successful build that then won't start on half your users' machines). And it makes sure that, if you don't use any such new features, your program doesn't have load-time dependencies on anything that didn't exist in 10.6.
Total noob here trying to get OpenCV working on Python through Homebrew. I searched everywhere extensively and couldn't find an answer intelligible to me. 99% of what I have done for this install is blindly follow forum posts, though I am beginning to get an understanding of what all this means.
Installed software:
OS 10.7.4
Xcode 4.4.1
-Command Line Tools
HomeBrew
-Python
-GFortran
-OpenCV
1. write this on first line of .bash_profile and save and restart Mac
export PYTHONPATH="/usr/local/lib/python2.7/site-packages:$PYTHONPATH"
2. open IDLE located at /usr/local/Cellar/python/2.7.3
.>>> import cv
Traceback (most recent call last):
File "", line 1, in
import cv
File "/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cv.py", line 1, in
ImportError: No module named cv2.cv
3. Go to Terminal to check PATH and PYTHONPATH
myname-MacBook-Pro:~ myname$ set
.#edited out unnecessary lines
PATH=/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
PYTHONPATH=/usr/local/lib/python2.7/site-packages:
1) What does my PATH need to be? I know its comically out of whack from repeated attempts.
2) Why isnt IDLE using this PYTHONPATH?
3. And most importantly, WHAT DO I NEED TO DO OVERALL TO JUST GET AN ICON, ON MY DOCK, THAT I CAN CLICK, THAT OPENS A PROGRAM, WHERE I CAN CODE WONDERFUL PYTHON WITH MAGNIFICENT OPENCV.
Thank you very much for any help you can send my way. I have been attempting to solve this problem for the last 3 days and would be very very appreciative of any help.
So IDLE is a regluar application not a commandline program that you run from bash, so it's not going to read your .bash_profile or your environment variables like PYTHONPATH.
The good news is, there is a way to get IDLE to recognise new python modules which might be in unusual locations, they just need to be referenced from a place where IDLE expects them to be, which is the site-packages directory. The confusing part is that you probably have more than one version of Python installed since Python is installed by default in Mac OSX and you've also installed it with homebrew (and it looks like you've tried macports as well).
Based on the path in the error, we know that IDLE is looking for the module in /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ which is the homebrew installation.
It looks like you somehow have the cv module there or linked in the site-packages directory but you're missing some other necessary file(s).
I have not installed OpenCV myself, but from the instructions here: http://jjyap.wordpress.com/2014/05/24/installing-opencv-2-4-9-on-mac-osx-with-python-support/ It looks like you need to also symlink the opencv cv2.so file into your site-packages directory from the opencv files you got through homebrew. (note the path for your site-packages directory is different from the instructions in the link).
I used to use Python 2.7 and then IDLE was working. I uninstalled it and installed Python 3.1.
Right now Idle cannot launch. What should i do to get it running?
NOTE:
I tried c:\Python31\pythonw.exe c:\Python31\Lib\idlelib\idle.py
i uninstalled 3.1 and installed back 2.7, not working neither...
I got the same problem on window 10. Steps to solve the problem:
Locate the .idlerc folder in your profile directory (e.g. C:\Users\{your-username} without the braces).
Delete the .idlerc directory.
It worked for me...
In the past, I've often found that when I had some issues with the python.org version of some Python release, specifically on Windows, installing instead the activepython version of the same release, from ActiveState, made the problems go away. So, in your shoes, the first thing I would try would be ActivePython (I don't think they have a 2.7 yet -- it's probably been around for too short a time yet -- but they definitely do have a 3.1).
EDIT: Versions 2.5, 2.6, 2.7, 3.2, 3.3, and 3.4 have been added.
I too faced the same problem. But at last solved like this -->
Run Python\Lib\idlelib\idle.py as admin, i got the error that the file "recent-files.lst" can't be opened.
So go to your home folder, show hidden files, click on .idlerc and delete the file named "recent-files". Now IDLE is working...
My system is Win7/64 Enterprise edition and the Python version is 2.7.3 (I need this one...).
This is what I got when I ran idle.py from the command window:
"
C:\Python27\Lib\idlelib>idle.py
Traceback (most recent call last):
File "C:\Python27\Lib\idlelib\idle.py", line 11, in <module>
idlelib.PyShell.main()
File "C:\Python27\Lib\idlelib\PyShell.py", line 1406, in main
root = Tk(className="Idle")
File "C:\Python27\lib\lib-tk\Tkinter.py", line 1685, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
{C:\Program Files (x86)\CSR\BlueSuite 2.5.0} C:/Python27/lib/tcl8.5 C:/lib/t
cl8.5 C:/lib/tcl8.5 C:/library C:/library C:/tcl8.5.2/library C:/tcl8.5.2/librar
y
This probably means that Tcl wasn't installed properly.
"
Indeed there was no "tcl8.5" folder in any of the listed above place but it was under:
"C:\Python27\tcl".
When I copied it under "C:\Python27\lib" then IDLE started (with some other warnings but this seems related to my corp environment...)
In conclusion this looks like either an installer failing to copy the folder where it is supposed to or failing to set up some environment variables correctly or there's an actual bug int the release likely to show up on Win7/64 on certain edition(s).
I am not a Python expert enough to debug Python itself, so please somebody take it from here...in the meantime I will see if the "workaround" is good enough :-)
Just try to delete the files which end with .idlerc in your profile.
1. Enter <win-r>, and type %USERPROFILE%\.idlerc
2. delete all files in idlerc folder
3. it works on my PC(win7 OS)
I ran into this weird situation also, and did a bit of troubleshooting. As a rigorous task, uninstalling, and re-installing the versions of python(2.6, 2.7, 3.1) and all my associated extensions and other site packages: in addition to the subsequent options that others have provided, that may have, or may not have, helped fix issues with the IDLE working properly. I found and error on my part, installing a 32 bit .msi on a 64 bit system causes a runtime .dll error with tkinter and therfore, causes IDLE to not start up properly, or not at all. Be mindful, and don't be a blind bat like me... :)
Once I copied the C:\Python27\tcl\tcl8.5 folder to C:\Python27\Lib as suggested in Bogdan's answer the error message "This probably means that Tcl wasn't installed properly" went away. Instead I started seeing "This probably means that tk wasn't installed properly". I had to copy the C:\Python27\tcl\tk8.5 folder to C:\Python27\Lib as well. Once I did that running idle.py from the command line in C:\Python27\Lib\idlelib was error-free.
Run python setup program, change python 2x, choose to entirely remove tcl/tk, proceed, then run setup again, change python again, on the tcl\tk choose entire feature will be installed, proceed.
It worked for me.
Even I was facing same issue with my code, But It is resolved now.
I was using 2.6 which was having old version of Xlrd, so I updated xlrd in 2.7 using pip and I opened my file with 2.7 and it works.
Delete the .idlerc directory as suggested above, run the python installer again and choose repair. If needed associate the .py files with the python.exe executable in Python27 folder. This worked for me after removing python 3.7.