This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients MartyMacGyver, ned.deily, serhiy.storchaka, steve.dower, terry.reedy, tim.golden, zach.ware
Date 2015-04-20.01:27:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429493249.21.0.301764715591.issue23982@psf.upfronthosting.co.za>
In-reply-to
Content
I am im favor of adding documentation for the existing tkinter TclVerion and TkVersion attributes to the tkinter section of the Standard Library reference as well as documenting a form of tkinter.Tcl().call('info', 'patchlevel') and/or tkinter.Tk().call('info', 'patchlevel') to return the full patchlevel string.  These spellings will work with every supported version of tkinter, Tcl, Tk, and platform.  Note that, while Tcl and Tk do have independent patch level strings, Tcl and Tk should normally always be installed at the same patch level; AFAIK, they are always released simultaneously upstream and are intended to be installed together.  If one were to add Tcl and Tk patchlevel attributes to tkinter, the code should be careful to dynamically get patchlevels via the equivalent of the above calls, and should not use the compile-time strings from Tcl/Tk include files tcl.h and tk.h, since on many platforms Tcl and Tk are installed as shared libraries and can be updated to a new patch level independently of the Python distribution.

As far as documenting the exact version of Tcl/Tk used in building the Python provided by a python.org Windows installer, that's a special case of documenting the versions of all third-party libraries used in the build.  I believe all of the information is available in the source tree PCBuild project files: Steve or Zach should be able to address whether that info is and/or should be available as part of the install process.  Adding all of that info to the release download page on python.org would be overkill as would a new PEP or a modification to PEP 101, IMO.  We do include general license information for possibly-included third-party libraries at the end of the license page in the release documentation set (https://docs.python.org/3/license.html) but, correctly, do not include specific version numbers there.  As a data point, for the python.org OS X installers, we now do include the specific version numbers of included libraries when producing the installer license file displayed as part of the installation process on OS X, with a link to the documentation set license page for the full text of the third-party licenses (see the attached jpg for an example).
History
Date User Action Args
2015-04-20 01:27:29ned.deilysetrecipients: + ned.deily, terry.reedy, tim.golden, zach.ware, serhiy.storchaka, steve.dower, MartyMacGyver
2015-04-20 01:27:29ned.deilysetmessageid: <1429493249.21.0.301764715591.issue23982@psf.upfronthosting.co.za>
2015-04-20 01:27:29ned.deilylinkissue23982 messages
2015-04-20 01:27:28ned.deilycreate