[Python-Dev] Merge the string_methods tag?
Barry A. Warsaw
bwarsaw at cnri.reston.va.us
Tue Jun 29 01:04:55 CEST 1999
>>>>> "SM" == Skip Montanaro <skip at mojam.com> writes:
SM> Well, when the CPP macro is undefined, the behavior from
SM> Python should be unchanged, yes? Am I missing something?
SM> There are string methods and what else involved in the
There are a few additions to the C API, but these probably don't need
to be ifdef'd, since they don't change the existing semantics or
abstract.c has some code cleaning and reorganization, but the public
API and semantics should be unchanged.
Builtin long() and int() have grown an extra optional argument, which
specifies the base to use. If this extra argument isn't given then
they should work the same as in the main branch. Should we ifdef out
the extra argument?
SM> If string.py has to test to see if "".capitalize yields an
SM> AttributeError to decide what to do, I think that sort of
SM> change will be simple enough to accommodate.
Basically what I've got is to move the main-branch string.py to
stringold.py and if you get an attribute error on ''.upper I do a
"from stringold import *". I've also got some hackarounds for
test_string.py to make it work with or without string methods.
SM> Any new code that gets well-exercised now before string
SM> methods become widely available is all to the good in my
SM> opinion. It's not fixing something that ain't broke, more
SM> like laying the groundwork for new directions.
Agreed. I'll check my changes in shortly. The ifdef will only
disable the string methods. long() and int() will still accept the
More information about the Python-Dev