There is an SF report that Pmw gets TypeErrors under Py2.3 but not under previous versions of Python: www.python.org/sf/697591 There are three parts to the story: 1. a method in _tkinter.c was changed (probably appropriately) to occassionally return ints in addition to strings. 2. Pmw used string.atoi() to coerce the result to an int. This should probably be changed, but I don't want existing Pmw to suddenly fail under 2.3. 3. String.atoi(s) works by calling int(s,10). It is the ten part that makes int() raise a TypeError. The long way to fix this bug is to 1) have Neal or MvL research the propriety of the changes to _tkinter and possibly find that they needed to be done and have to be left alone and 2) have the Pmw folks update their code to not use string.atoi(s) when s is not a string (seems like a bug, but s used to always be a string when they wrote the code). Step 2 doesn't help existing users of Pmw unless they get a bugfix release. The shortcut is to fix something that isn't broken and have string.atoi stop automatically appending the ten to the int() call. Current string.atoi: def atoi(s, base=10): return _int(s, base) Proposed string.atoi: def atoi(s, *args): return _int(s, *args) The shortcut has some appeal because it lets the improvements to _tkinter stay in place and allows existing Pmw installations to continue to operate. Otherwise, one of the two has to change. Does anyone think changin string.atoi is the wrong way to go? Raymond Hettinger
Raymond Hettinger <raymond.hettinger@verizon.net>:
It looks harmless to me. My only concern would be if it started making things like string.atoi("0x10") accepted, but a quick experiment suggests that this would not be the case (in 2.2, at least). Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
"Raymond Hettinger" <raymond.hettinger@verizon.net> writes:
Is Pmw using _tkinter directly, or indirectly via Tkinter? Neither answer to this question makes sense: a) if Pmw uses _tkinter directly, it should not receive int results. b) if Pmw uses Tkinter, it should not find methods that used to return strings but now return ints. If, for some strange reason, b) does happen, applications can invoke Tkinter.wantobjects = 0 to restore the old behaviour.
Does anyone think changin string.atoi is the wrong way to go?
It would change the historical behaviour, I believe: string.atoi(10) used to give a TypeError even back in Python 1.5. Regards, Martin
Raymond Hettinger wrote:
Yes, because it changes the semantics. string.atoi() would suddenly start to accept non-strings like integers, floats, etc. My suggestion would be to carefully reconsider the changes to _tkinter. If it's true that a method can now return strings *and* integers which previously only returned strings, then such a change is clearly not backward compatible. I'd create a new method for the new semantics in that case. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 18 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 14 days left EuroPython 2003, Charleroi, Belgium: 98 days left
That's my gut feeling too. --Guido van Rossum (home page: http://www.python.org/~guido/)
[RH]
Does anyone think changin string.atoi is the wrong way to go?
[MAL]
[GvR]
That's my gut feeling too.
I misspoke. I agree with MAL that string.atoi() shouldn't be changed. But I didn't mean to imply that I wanted the changes to _tkinter and Tkinter to be rolled back. --Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger <raymond.hettinger@verizon.net>:
It looks harmless to me. My only concern would be if it started making things like string.atoi("0x10") accepted, but a quick experiment suggests that this would not be the case (in 2.2, at least). Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
"Raymond Hettinger" <raymond.hettinger@verizon.net> writes:
Is Pmw using _tkinter directly, or indirectly via Tkinter? Neither answer to this question makes sense: a) if Pmw uses _tkinter directly, it should not receive int results. b) if Pmw uses Tkinter, it should not find methods that used to return strings but now return ints. If, for some strange reason, b) does happen, applications can invoke Tkinter.wantobjects = 0 to restore the old behaviour.
Does anyone think changin string.atoi is the wrong way to go?
It would change the historical behaviour, I believe: string.atoi(10) used to give a TypeError even back in Python 1.5. Regards, Martin
Raymond Hettinger wrote:
Yes, because it changes the semantics. string.atoi() would suddenly start to accept non-strings like integers, floats, etc. My suggestion would be to carefully reconsider the changes to _tkinter. If it's true that a method can now return strings *and* integers which previously only returned strings, then such a change is clearly not backward compatible. I'd create a new method for the new semantics in that case. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Mar 18 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
Python UK 2003, Oxford: 14 days left EuroPython 2003, Charleroi, Belgium: 98 days left
That's my gut feeling too. --Guido van Rossum (home page: http://www.python.org/~guido/)
[RH]
Does anyone think changin string.atoi is the wrong way to go?
[MAL]
[GvR]
That's my gut feeling too.
I misspoke. I agree with MAL that string.atoi() shouldn't be changed. But I didn't mean to imply that I wanted the changes to _tkinter and Tkinter to be rolled back. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Greg Ewing -
Guido van Rossum -
M.-A. Lemburg -
martin＠v.loewis.de -
Raymond Hettinger