-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Tkinter doesn't support large integers #61044
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A long time Tcl got support first 64-bit integers, and then arbitrary size integers. Python also supports arbitrary size integers. However Tkinter supports only C long integers. For example, on 32-bit platform: >>> import tkinter
>>> t = tkinter.Tk()
>>> t.tk.call('expr', 2**30)
1073741824
>>> t.tk.call('expr', 2**31)
<wideInt object at 0x9122518>
>>> t.tk.call('expr', 2**63)
<bignum object at 0x9126010> Those <wideInt object> and <bignum object> are not usable from Python. Potentially this can cause errors in some rare circumstances. I'm working on a patch, but was faced with a problem. Tcl provides functions for conversions between Bignum Tcl object and mp_int, but it does not provide all functions for conversions between mp_int and bytes sequence. Which is better, add libtommath library to CPython dependencies, or implement the missing functionality manually? Or may be use haxadecimal representation for conversions? |
Here is a patch which adds support of "wideInt" and "bignum" Tcl types. |
I reclassify this as enhancement until the real bug is not found. |
Patch updated. |
Patch synchronized with tip and fixed support of Tcl <8.5. |
Here is test failure related to this issue: http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/156/steps/test/logs/stdio test test_tk failed -- Traceback (most recent call last):
File "D:\buildarea\2.7.bolen-windows8\build\lib\lib-tk\test\test_tkinter\test_widgets.py", line 91, in test_use
wid = parent.winfo_id()
File "D:\buildarea\2.7.bolen-windows8\build\lib\lib-tk\Tkinter.py", line 839, in winfo_id
self.tk.call('winfo', 'id', self._w))
TclError: integer value too large to represent |
Updated patch now supports wideInt if PY_LONG_LONG is not defined or is not equal to Tcl_WideInt. getint() also now supports big integers (currently it returns ambiguous result for values outside the range of C signed int). As far as this issue causes random tests failures, may be it makes sense to apply the patch to maintained releases. On other hand, looks as this happens very rarely. |
I'm all for fixing random test failures. |
But there is a risk to break Python builds with old Tcl/Tk. We dropped support of Tcl/Tk older than 8.4 in 3.5, but theoretically 2.7 should work with older versions. It was not tested for years, we have no build bots with 8.3, and I manually test Python only with 8.4+ (it is harder to build 8.3, not mentioning older versions). But AFAIK wideInt was not supported in 8.3, so code and tests should be adapted for optional support of integers outside 32-bit range. I could try to build 8.3 and adapt the patch, but I'm not very motivated in this. And I can't take the responsibility of committing the patch blindly, without testing with different options. |
It's up to you. Since 2.7 is so long lived, we've had to gradually alter supported library versions (e.g. for bsddb). |
New changeset 42a6449e577c by Serhiy Storchaka in branch '2.7': New changeset a6f4d8fa7ab8 by Serhiy Storchaka in branch '3.4': New changeset 9291b28157e1 by Serhiy Storchaka in branch 'default': |
New changeset 9905fb0b5885 by Serhiy Storchaka in branch '2.7': New changeset 1d2444273b3d by Serhiy Storchaka in branch '3.4': New changeset 2398dba039f3 by Serhiy Storchaka in branch 'default': |
test_expr_bignum() should tolerate the long type: http://buildbot.python.org/all/builders/x86%20Tiger%202.7/builds/3007/steps/test/logs/stdio ====================================================================== Traceback (most recent call last):
File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_tcl.py", line 443, in test_expr_bignum
self.assertIsInstance(result, type(int(result)))
AssertionError: -2147483648L is not an instance of <type 'int'> In fact, I don't understand the test self.assertIsInstance(result, type(int(result))). What do you expect from type(int(x)): int or long depending on the value of x? The problem is that an intermediate result may be a long and so tcl.call('expr', ..) returns a long even if it may fit into a small int. I suggest to simply drop the test self.assertIsInstance(result, type(int(result))). |
It is important that the result is an int at least for small ints. So I prefer to keep limited test.
+ if abs(result) < 2**31: |
New changeset 350c78a92046 by Serhiy Storchaka in branch '2.7': |
There is at least one buildbot that now fails to build _tkinter. http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%202.7/builds/2457/steps/test/logs/stdio |
New changeset 8ab077c22fbf by Serhiy Storchaka in branch '2.7': New changeset 7f1622478d17 by Serhiy Storchaka in branch '3.4': New changeset 7a7f09528866 by Serhiy Storchaka in branch 'default': |
This didn't help. Actually we should turn on bignum support only since 8.5.8, because tclTomMath.h was broken before. But this is not related, because tclTomMath.h is not found itself on this buildbot. |
Ah, we should also test full version of 8.6, because bignums was not supported in earlier alphas and betas (if I remember correctly, this buildbot uses beta version of 8.6). TK_VERSION_HEX packs fields in wrong order, not suitable for comparing of non-final releases. It's value for 8.6a3 is larger than 8.6.1. Here is a patch that adds TK_HEX_VERSION with correctly packed fields and turn off bignum support in non-final 8.6. |
New changeset 5116916e4f7f by Serhiy Storchaka in branch '2.7': |
New changeset 4bf210f59ac6 by Serhiy Storchaka in branch '2.7': New changeset 97519d85b5c8 by Serhiy Storchaka in branch '3.4': New changeset 701b830abbf0 by Serhiy Storchaka in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: