Tkinter, IDLE: Future Tcl and Tk can have differing version/patchlevel

[chrstphrchvz]

Tk 8.7 will be compatible with both Tcl 8.7 and Tcl 9.0; there is no Tk 9.0 currently in development. The version and/or patchlevel of Tcl and Tk will not necessarily be identical, but there are places in Tkinter code which assume they are. A few examples which I am aware of:

cpython/Lib/idlelib/help_about.py

Line 79 in 48b3617

tk_patchlevel = self.info_patchlevel()

cpython/Lib/test/test_tkinter/support.py

Line 103 in 48b3617

_tk_patchlevel = tcl.info_patchlevel()

cpython/Lib/test/test_tcl.py

Line 28 in 48b3617

_tk_patchlevel = tcl.info_patchlevel()

Linked PRs

• gh-104496: IDLE - fix About for mixed tcl/tk versions #104585
• [3.11] gh-104496: IDLE - fix About for mixed tcl/tk versions (GH-104585) #104587
• gh-104496: Use correct Tcl or Tk version in Tkinter tests #107688
• [3.12] gh-104496: Use correct Tcl or Tk version in Tkinter tests (GH-107688) #107709
• [3.11] gh-104496: Use correct Tcl or Tk version in Tkinter tests (GH-107688) #107719

[terryjreedy]

Is there different code to get tk version/patchlevel?

[chrstphrchvz]

Tcl version: tkinter.Tcl().tk.call('info', 'tclversion') and tkinter.Tcl().globalgetvar('tcl_version')
Tcl patchlevel: tkinter.Tcl().tk.call('info', 'patchlevel') and tkinter.Tcl().globalgetvar('tcl_patchLevel')
Tk version: tkinter.Tk().globalgetvar('tk_version')
Tk patchlevel: tkinter.Tk().globalgetvar('tk_patchLevel')

This issue is likely more applicable to version checks which need to be added (e.g. for issues like #104497) rather than existing ones (since checking for Tcl 8.6 is sufficient for knowing e.g. whether Tk has PNG support).

For this issue, I am less inclined to propose a solution on my own without prior input. I hesitate to introduce more ways to retrieve the version/patchlevel. Personally, I try to rely on the Tcl package vcompare command rather than retrieve/expose the version/patchlevel and attempt to reimplement correct version comparison logic in Python or Perl.

[terryjreedy]

https://github.com/python/cpython/blob/48b3617de491f00a3bf978b355074cc8e228d61b/Lib/tkinter/__init__.py#LL1081C1-L1084C1 has the following, which includes all 'patchlevel' occurrences in the file.

    def info_patchlevel(self):  # Method of Misc, a base for toplevel and widgets. [comment added]
        """Returns the exact version of the Tcl library."""
        patchlevel = self.tk.call('info', 'patchlevel')
        return _parse_version(patchlevel)

Is this call, the one that IDLE currently uses, returning the tcl or tk version?

[chrstphrchvz]

https://github.com/python/cpython/blob/48b3617de491f00a3bf978b355074cc8e228d61b/Lib/tkinter/__init__.py#LL1081C1-L1084C1 has the following, which includes all 'patchlevel' occurrences in the file.

    def info_patchlevel(self):  # Method of Misc, a base for toplevel and widgets. [comment added]
        """Returns the exact version of the Tcl library."""
        patchlevel = self.tk.call('info', 'patchlevel')
        return _parse_version(patchlevel)

Is this call, the one that IDLE currently uses, returning the tcl or tk version?

This always returns the Tcl patchlevel.

[terryjreedy]

I am not familiar with tcl in general, just enough to translate tk commands into tkinter. Are the 'package' commands available with the tcl we install with Windows and macOS?

[chrstphrchvz]

Are the 'package' commands available with the tcl we install with Windows and macOS?

Yes.

[serhiy-storchaka]

I hesitate to introduce more ways to retrieve the version/patchlevel. Personally, I try to rely on the Tcl package vcompare command rather than retrieve/expose the version/patchlevel and attempt to reimplement correct version comparison logic in Python or Perl.

Seems that package vcompare only works with dot separated numbers. It does not work with versions like 8.7a5. On other hand, it works with versions like 8.7.6.5.4.3.2.1, but I am sure that Tcl and Tk libraries have more rigid version structure.

On other hand, Python already uses sys.version_info-like named tuples for versions of different libraries, and I think it should use it more.

I thought about introducing more ways to retrieve the structured version info, but I hesitate between method get_tk_patchLevel() and property tk_patchLevel.

[chrstphrchvz]

Seems that package vcompare only works with dot separated numbers. It does not work with versions like 8.7a5.

How so? Section “Version numbers” in the Tcl documentation for the package command says that versions containing a or b are accepted, and that is the behavior I observe in tclsh:

% package vcompare 8.7a5 8.6.13
1
% package vcompare 8.6b3 8.7a5
-1

[chrstphrchvz]

Maybe Tkinter can wait to act on this issue. There is still active disagreement among Tcl/Tk core developers (most recently in https://sourceforge.net/p/tcl/mailman/tcl-core/thread/3deb862a-cc07-4b6f-ae15-1916a998eac2%40Spark/) over the original plan to decouple Tcl and Tk versions and release Tcl 8.7, Tcl 9.0, and Tk 8.7; some of them only want Tcl/Tk 9.0.

[serhiy-storchaka]

I am sorry, I looked in the 8.4 branch.

[chrstphrchvz]

Ah, understandable. The old documentation does tend to show up in search engine results. The package command alpha/beta version support was added in Tcl 8.5 (TIP 268)

[serhiy-storchaka]

It is just that I did not checked what branch was checked out in my worktree. I thought it was the latest version, but for some reasons it was 8.4.

[hugovk]

Anything left to do here, or can we close the issue?

[chrstphrchvz]

I think it is still too early to know what else needs to be done for this issue. I am not aware of any official announcement from Tcl/Tk on what their plan is now, but some of its inner developer circle still insists that Tk 9.0 be released and not Tk 8.7.

[chrstphrchvz]

The latest I have heard is that they want to release Tcl 9.0 and Tk 9.0 first, and then Tcl 8.7 and Tk 8.7 either later or not at all. I would still suggest version checks be careful about which of 8.6/8.7/9.0, Tcl or Tk, and “patchlevel” or “version” to check.

[dkfellows]

Tcl 9.0 will definitely ship before Tcl 8.7 (which is a "maybe, if there's demand great enough and developer effort enough"). Tk is a bit less certain, but there's a bit of head of steam getting up to go to 9.0 there too just so we can delete some really old and nasty undocumented cruft that I truly hope you're not depending on.

We test Tcl 9.0 and Tk 8.7 as a combination, as well as Tcl 9.0 and Tk 9.0. We do not test Tcl 8.7 with Tk 9.0. Test result summaries are online.

---

The proper, official methods for getting the version of Tk are:

• set tk_version — returns 8.6, 8.7, 9.0 (i.e., just major.minor).
• set tk_patchLevel — returns 8.6.12, 8.7a3, 9.0b1 (i.e., major.minor.patch with possible alpha/beta indicator)
• package require Tk — returns 8.6.12, 8.7a3, 9.0b1 (same semantics as above, and loads the package if it wasn't already present)
• In the shell script tkConfig.sh (which should be installed in any binary installation of Tk, possibly with an alternate name if there are Linux distributions about) there will be some variables like this:

  TK_VERSION='9.0'
  TK_MAJOR_VERSION='9'
  TK_MINOR_VERSION='0'
  TK_PATCH_LEVEL='b1'

  I think you can figure out what they mean. They're the only supported method (that I'm aware of) for getting the version without loading the Tk package in a Tcl interpreter. In particular, tkConfig.sh is intended for use during setting up a build process that depends on Tk.

There are equivalents for Tcl, as well as info tclversion and info patchlevel. (I don't know why we never made tk patchlevel or tk version.)

[chrstphrchvz]

The proper, official methods for getting the version of Tk are:

• set tk_version — returns 8.6, 8.7, 9.0 (i.e., just major.minor).
• set tk_patchLevel — returns 8.6.12, 8.7a3, 9.0b1 (i.e., major.minor.patch with possible alpha/beta indicator)
• package require Tk — returns 8.6.12, 8.7a3, 9.0b1 (same semantics as above, and loads the package if it wasn't already present)

In Python syntax, the first two are still probably better done as e.g. tkinter.Tk().globalgetvar('tk_version') (which relies on Tcl_GetVar2Ex()) as in my above comment rather than trying to directly translate the Tcl syntax into tkinter.Tcl().tk.call('set', 'tk_version') or tkinter.Tcl().tk.eval('set tk_version').

• In the shell script tkConfig.sh (which should be installed in any binary installation of Tk, possibly with an alternate name if there are Linux distributions about) there will be some variables like this:

  TK_VERSION='9.0'
  TK_MAJOR_VERSION='9'
  TK_MINOR_VERSION='0'
  TK_PATCH_LEVEL='b1'

  I think you can figure out what they mean. They're the only supported method (that I'm aware of) for getting the version without loading the Tk package in a Tcl interpreter. In particular, tkConfig.sh is intended for use during setting up a build process that depends on Tk.

The only times I am aware that Tkinter needs to know Tcl/Tk versions without an interpreter are when configuring and compiling. But that is done using the macros from <tcl.h> and <tk.h>, after either providing the right Tcl/Tk compiler flags to the configure script or by using pkg-config (which is what many other FOSS projects use; Tcl/Tk provides much less via pkg-config than in tclConfig.sh/tkConfig.sh, but with https://core.tcl-lang.org/tcl/info/4b11db28e63d there now seems to be just enough for Tkinter to build).

[terryjreedy]

Has it been determined whether tcl/tk 9 will have full unicode support? Is there any approximate target date?

[terryjreedy]

In #124111 , Mark Culler, member of the Tcl Core Team (TCT), says "The TclTk project has decided that there will be no release of the 8.7 branches." and "8.6.15 and 9.0 versions of Tcl and Tk currently have release candidates, while Tcl and Tk 8.7 have never reached beta". Also, 9.0 will have full unicode support (no CESU-8).