Mailing List Archive: Merge the string_methods tag?

Merge the string_methods tag?

MHammond at skippinet

Jun 18, 1999, 1:31 AM

Post #1 of 8 (2075 views)

Ive been running the string_methods tag (term?) under CVS for quite some
time now, and it seems to work perfectly. I admit that I havent stressed
the string methods much, but I feel confident that Barry's patches havent
broken existing string code.

Also, I find using that tag with CVS a bit of a pain. A few updates have
been checked into the main branch, and you tend to miss these (its a pity
CVS can't be told "only these files are affected by this tag, so the rest
should follow the main branch." I know I can do that personally, but that
means I personally need to know all files possibly affected by the branch.)
Anyway, I digress...

I propose that these extensions be merged into the main branch. The main
advantage is that we force more people to bash on it, rather than allowing
them to make that choice <wink>. If the Unicode type is also considered
highly experimental, we can make a new tag for that change, but that is
really quite independant of the string methods.

Mark.

Re: Merge the string_methods tag? [ In reply to ]

Jun 18, 1999, 7:51 AM

Post #2 of 8 (2044 views)

> Ive been running the string_methods tag (term?) under CVS for quite some
> time now, and it seems to work perfectly. I admit that I havent stressed
> the string methods much, but I feel confident that Barry's patches havent
> broken existing string code.
>
> Also, I find using that tag with CVS a bit of a pain. A few updates have
> been checked into the main branch, and you tend to miss these (its a pity
> CVS can't be told "only these files are affected by this tag, so the rest
> should follow the main branch." I know I can do that personally, but that
> means I personally need to know all files possibly affected by the branch.)
> Anyway, I digress...
>
> I propose that these extensions be merged into the main branch. The main
> advantage is that we force more people to bash on it, rather than allowing
> them to make that choice <wink>. If the Unicode type is also considered
> highly experimental, we can make a new tag for that change, but that is
> really quite independant of the string methods.

Hmm... This would make it hard to make a patch release for 1.5.2
(possible called 1.5.3?). I *really* don't want the string methods to
end up in a release yet -- there are too many rough edges (e.g. some
missing methods, should join str() or not, etc.).

I admit that managing CVS branches is painful. We may find that it
works better to create a branch for patch releases and to do all new
development on the main release... But right now I don't want to
change anything yet.

In any case Barry just went on vacation so we'll have to wait 10
days...

--Guido van Rossum (home page: http://www.python.org/~guido/)

Re: Merge the string_methods tag? [ In reply to ]

Jun 27, 1999, 3:11 PM

Post #3 of 8 (2041 views)

Guido> Hmm... This would make it hard to make a patch release for 1.5.2
Guido> (possible called 1.5.3?). I *really* don't want the string
Guido> methods to end up in a release yet -- there are too many rough
Guido> edges (e.g. some missing methods, should join str() or not,
Guido> etc.).

Sorry for the delayed response. I've been out of town. When Barry returns
would it be possible to merge the string methods in conditionally (#ifdef
STRING_METHODS) and add a --with-string-methods configure option? How hard
would it be to modify string.py, stringobject.c and stropmodule.c to carry
that around?

Skip Montanaro | http://www.mojam.com/
skip@mojam.com | http://www.musi-cal.com/~skip/
518-372-5583

Re: Merge the string_methods tag? [ In reply to ]

bwarsaw at cnri

Jun 28, 1999, 2:20 PM

Post #4 of 8 (2042 views)

>>>>> "SM" == Skip Montanaro <skip@mojam.com> writes:

SM> Sorry for the delayed response. I've been out of town. When
SM> Barry returns would it be possible to merge the string methods
SM> in conditionally (#ifdef STRING_METHODS) and add a
SM> --with-string-methods configure option? How hard would it be
SM> to modify string.py, stringobject.c and stropmodule.c to carry
SM> that around?

How clean do you want this separation to be? Just disabling the
actual string methods would be easy, and I'm sure I can craft a
string.py that would work in either case (remember stropmodule.c
wasn't even touched). There are a few other miscellaneous changes
mostly having to do with some code cleaning, but those are probably
small (and uncontroversial?) enough that they can either stay in, or
be easily understood and accepted (optimistic aren't I? :) by Guido
during the merge.

I'll see what I can put together in the next 1/2 hour or so.

-Barry

Re: Merge the string_methods tag? [ In reply to ]

Jun 28, 1999, 2:37 PM

Post #5 of 8 (2046 views)

>>>>> "BAW" == Barry A Warsaw <bwarsaw@cnri.reston.va.us> writes:

>>>>> "SM" == Skip Montanaro <skip@mojam.com> writes:

SM> would it be possible to merge the string methods in conditionally
SM> (#ifdef STRING_METHODS) ...

BAW> How clean do you want this separation to be? Just disabling the
BAW> actual string methods would be easy, and I'm sure I can craft a
BAW> string.py that would work in either case (remember stropmodule.c
BAW> wasn't even touched).

Barry,

I would be happy with having to manually #define STRING_METHODS in
stringobject.c. Forget about the configure flag at first. I think the main
point for experimenters like myself is that it is a hell of a lot easier to
twiddle a #define than to try merging different CVS branches to get access
to the functionality. Most of us have probably advanced far enough on the
Emacs, vi or Notepad learning curves to handle that change, while most of us
are probably not CVS wizards.

Once it's in the main CVS branch, you can announce the change or not on the
main list as you see fit (perhaps on python-dev sooner and on python-list
later after some more experience has been gained with the patches).

Skip

Re: Merge the string_methods tag? [ In reply to ]

bwarsaw at cnri

Jun 28, 1999, 3:04 PM

Post #6 of 8 (2042 views)

>>>>> "SM" == Skip Montanaro <skip@mojam.com> writes:

SM> I would be happy with having to manually #define
SM> STRING_METHODS in stringobject.c. Forget about the configure
SM> flag at first.

Oh, I agree -- I wasn't going to add the configure flag anyway :)
What I meant was how much of my changes should be ifdef-out-able?
Just the methods on string objects? All my changes?

-Barry

Re: Merge the string_methods tag? [ In reply to ]

Jun 28, 1999, 3:30 PM

Post #7 of 8 (2045 views)

BAW> Oh, I agree -- I wasn't going to add the configure flag anyway :)
BAW> What I meant was how much of my changes should be ifdef-out-able?
BAW> Just the methods on string objects? All my changes?

Well, when the CPP macro is undefined, the behavior from Python should be
unchanged, yes? Am I missing something? There are string methods and what
else involved in the changes? If string.py has to test to see if
"".capitalize yields an AttributeError to decide what to do, I think that
sort of change will be simple enough to accommodate. Any new code that gets
well-exercised now before string methods become widely available is all to
the good in my opinion. It's not fixing something that ain't broke, more
like laying the groundwork for new directions.

Skip

Re: Merge the string_methods tag? [ In reply to ]

bwarsaw at cnri

Jun 28, 1999, 4:04 PM

Post #8 of 8 (2038 views)

>>>>> "SM" == Skip Montanaro <skip@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