Fresh Win7 VC express debug build (F7), 2.7 only: fairly recent (last 3 months?) regression.

In debug console, import idlelib.idle. Try to Open a file. Get message that ostypeCount is used before initialized. If open python_d with F5 in VC, [break] takes me to VS debugger, which points to line 341 in tkFileFilter.c (where is that in the directory tree?).
    if (ostypeCount > 0 && ostypeList != NULL) {
I am slightly puzzled because it appears that line 234
    for (i=0; i<ostypeCount; i++) {
should have been executed first.

If I start the 2.7 console directly instead of under the debugger, I can ignore the message and open a file and everything *seems* normal. Most users would be less comfortable doing that, but I presume the message would not appear in a release build.

What Tk version do you use? This bug was fixed 5 years ago.

http://core.tcl.tk/tk/info/01ac8739ab148160b39d604439cdab1f4ebe4b0f

As I may have mentioned before, I *now* use the 'standard' one for Windows for each version of Python, as fetched by Tools/buildbots/external.bat. For 2.7 this is 8.5.2.  The reason I just noticed about a month ago is that I previously ran all repository builds with one version of tcl/tk, the latest -- and had no problems. When 3.4 switched to 8.6.0, I wanted to use that for the repository build also, but my impression is that 2.7 and 3.3 cannot run with 8.6. So I put each Python branch clone in a separate directory instead of side-by-side in one directory as recommended in the developer guide. (This is a nuisance.) I do not really understand why Windows users of 2.7 as saddled with such an old release of tcl/tk.

If there is nothing to be done about this, we can close it.

May be we should update Tcl/Tk on buildbots (issue20565).

Terry, could you try this again with a fresh build of Tcl/Tk 8.5.15?  Update your 2.7 to 2b8d9276ad5b or beyond and run Tools/buildbot/external.bat again, it should take care of it.

I'm going to go ahead and close this, since it should be fixed.  Terry, if you do find that this is still an issue, please reopen.

The problem is gone after re-running external.bat -- and manually copying the dlls into pcbuild. It there an open issue to fix the undocumented need to copy?

> Is there an open issue to fix the undocumented need to copy?

I don't think so.