I added a new 2.7 worktree, with 2.7 checked out to track origin (my github fork).  I built Python with tcl/tk 8.5.15.  Whoops, my fork had 2.7 at 2.7.13+.  Fetch upstream, merge upstream/2.7, and rebuild.  I noticed that tcl/tk 8.5.19 was downloaded.  But IDLE subsequently reported that tk was still at 8.5.15.  I renamed the 8.5.15 and the compiled tcltk directories, built again, and tcltk was recompiled to 8.5.19.  It seems that when new tcl/tk externals are downloaded, the compiled tcltk should be deleted.

If I understand, this part of the output says that there was no recompile of tcl/tk.

  _hashlib.vcxproj -> f:\dev\27\PCBuild\_hashlib_d.pyd
  _tkinter.c
     Creating library f:\dev\27\PCBuild\_tkinter_d.lib and object f:\dev\27\PCBuild\_tkinter_d.e
  xp
  _tkinter.vcxproj -> f:\dev\27\PCBuild\_tkinter_d.pyd
  _bsddb.c

My installed 2.7.15 also has tcl/tk at 8.5.15.  If tcl/tk was upgraded before this recent release, the upgrade did not take effect.  

When tcl/tk has been upgraded during 3.x alpha/beta periods, tcl/tk seems to have been recompiled when it should be.

The upstream update also caused the following updates:
Fetching bsddb-4.7.25.0...
Fetching openssl-1.0.2o...
Fetching sqlite-3.14.2.0...

There were new compiles to build
f:\dev\27\PCBuild\_sqlite3_d.pyd
f:\dev\27\PCBuild\ssleay_d.lib
f:\dev\27\PCBuild\_bsddb_d.pyd
so I presume these are ok and I can just delete the old directories.

> When tcl/tk has been upgraded during 3.x alpha/beta periods, tcl/tk seems to have been recompiled when it should be.


Terry, are you saying this was only a problem on 2.7?

Apparently so, which makes this irrelevant.

stage: resolved