Discoved this when using Pmw with 2.3a1 and a2 found atoi 
doesn't work properly. So, I wrote a small test:
------------------
import string
if __name__ == __main__:
   num = atoi(test, 10)
------------------

Always get and exception from  it and using Pmw that is the 
same:
<...>
python2.3/string.py, line 220
   return _int(s, base)
TypeError: int() can't convert non-string with explicit base

Seems to always pass a string like it asks for.
I can also reproduce by using the MenuBar.py and 
MainMenuBar.py in Pmw/Pmw1.1/demos.

I fixed it by looking at python2.3/stringold.py. I took the guts of 
atoi from there.

So it was:
---------------
def atoi(s, base=10) :
     return _int(s, base)

It is now:
--------------
def atoi(*args) :

    try:
       s = arg[0]
    except IndexError:
       raise TypeError('function requires a least one argument: %d 
given' % len(args))

    return apply(_int, args)

Hope this helps. Not sure if it is best way to fix it but solved all our 
errors using atoi for now. 
Let me know if you need more info. - jmurff@pacbell.net

Logged In: YES 
user_id=2138

I replaced the string.atoi() calls with calls to just int() in Pmw when I encountered this. I'm glad you filed this bug so I don't have to!

Logged In: YES 
user_id=80475

I'll take a look at this one.

Can you provide the value and type of the "test" variable 
when the exception was raised?

Also, please confirm that the test code meant to 
say:  "num = string.atoi(test, 10) ".

Logged In: YES 
user_id=454042

I tried all kinds of values for the test variable...
'str' "str" sys.argv[0]. They all complained  about invalid literal.
Pmw code showed other error. These used 'str' or a return from a method 
as i recall. Yes i meant "string.atoi" -- sorry :)

Logged In: YES 
user_id=80475

Values like 'str' are being properly flagged as invalid 
literals.  We need to find out the value and type that is 
causing the error in Pmw.  Can you insert a "print >> 
sys.stderr, type(s), repr(s), str(s)" at the beginning of the 
atoi() code.

The lines in the string.atoi() code have been around since 
Py1.6, so if this is a new error, then it means that the 
behavior of int(s, 10) has changed in subtle ways or that 
the object s has changed in some way.

I would like to fix only the thing that caused the error and 
avoid altering the string.atoi code which has been around 
for so long.

The easiest way to track this one down is to simplify the 
bug report to something like this:
  
string.atoi(s, 10)runs under Py2.2 but fails under Py2.3 
when s is UserString with the value of " 10".

BTW, a simpler workaround is to change string.atoi to:

def atoi(s, *args) : 
    return _int(s, *args) 

Logged In: YES 
user_id=2138

Looks like it's not a string.atoi problem, but a Pmw problem. I added the print >>sys.stderr, type(s), repr(s), str(s) and it shows this:

<type 'int'> 0 0

I'll try digging in Pmw to see if I can find the error.

I don't know if it's a Python 2.3 vs. 2.2 issue, or a Tcl/Tk AquaTk vs. X11 Tk issue. I see the problem with 2.3 and AquaTk but havn't tested other combos.

Logged In: YES 
user_id=454042

We don't see the problem in Python 2.1. In fact initially we fell back to 
2.1 but I don't want to stay there.

Logged In: YES 
user_id=80475

Corvus, did you have any luck finding the offending lines in 
PmW?

Can this bug be posted on PmW's SF site and closed here
or do you guys think something still needs to be fixed in 
Python?

Logged In: YES 
user_id=2138

I think the root cause of the issue may be in _tkinter.c. The return values from widget.cget() looks like they used to be only strings (python 2.2.2).

In Python 2.3, widget.cget() will return ints in stead of strings where it needs to.

My test code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a), a

Pmw assumes the return values of all cget calls will be strings.

If there's a bug here, it's just that Pmw doesn't yet support Python 2.3.

I don't think the issue is with Tcl/Tk as it looks to me like 8.3 returns an int for borderwidth, yet my Python 2.2.2 linked with that version of Tcl/Tk returns a string.

Logged In: YES 
user_id=80475

Neal,I saw that you've been maintaining _tkinter.c.  Do you 
have time to look into the behavior change for widget.cget
()?  

It would be great if PmW could be kept working under 
Py2.3.

Corvus, thanks for the precise bug report.  I think it gets 
to the heart of the matter.

Logged In: YES 
user_id=33168

I tried the test code which prints the type of borderwidth
from a frame.  In both 2.3 and 2.2.2 I get a string.  I'm
running with tk 8.3 on Linux.  What OS are you running?

Logged In: YES 
user_id=2138

I'm using MacOS X 10.2.4 and Tcl/Tk 8.4.2 with Python 2.3a2.

Logged In: YES 
user_id=33168

Martin, can you test this with Tk 8.4?

Logged In: YES 
user_id=21627

We have to separate issues. There is bug 698517, which is
caused by Tk now (8.4.2) passing the string "??" in places
where it would previously only  pass numbers, and patch
707701, which tries to work around this.

There appears to be an independent issue with Pmw, which I
suggest not to investigate further until somebody can
provide a reproducable test case, in Pmw (preferably
indicating the precise Pmw version).

Logged In: YES 
user_id=2138

This isn't a Pmw issue. I just built Python 2.2.2 with Tcl/Tk 8.4.1 and Python 2.3 with the same Tcl/Tk. This code:

import Tkinter
a = Tkinter.Frame()['borderwidth']
print type(a)

produces these results:

On python 2.2.2: 
        <type 'str'>

On python 2.3:
        <type 'int'>

So, there you have it. Python 2.3a2's tkinter isn't backwards compatable with 2.2.

I don't know if that's a problem or not. It's just an observation I came across while porting some older python code (which used Pmw) to 2.3.

Hope that helps!

Logged In: YES 
user_id=21627

Yes, the return type of some data changes, and yes, this is
not fully backwards compatible. But this is not a bug, but a
feature, see

http://www.python.org/doc/2.3a2/whatsnew/node16.html

In Tk, borderwidth *is* an integer, not a string.

Applications that cannot accept this change need to write

Tkinter.wantobjects=0

before creating the first tkapp object.

Logged In: YES 
user_id=2138

Excellent. I think this item should be closed now.

Also, I don't think it has anything to do with bug 698517.

Thanks and take care.

Logged In: YES 
user_id=21627

Ok, closing it - although I'm still curious as to what code
in Pmw broke with that change.