RetroSearch Browse

Tue Jun 29 01:04:55 CEST 1999 · https://mail.python.org/pipermail/python-dev/1999-June/095546.html

>>>>> "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
    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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/1999-June/095546.html below:

[Python-Dev] Merge the string_methods tag?