"SM" == Skip Montanaro email@example.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 SM> changes?
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 interfaces.
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 option argument.
Stay tuned, -Barry