Merge the string_methods tag?
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.
maybe not the right forum, but I suppose everyone here is using CVS, so... ...could anyone explain why I keep getting this error? $ cvs -z6 up -P -d ... cvs server: Updating dist/src/Tools/ht2html cvs [server aborted]: cannot open directory /projects/cvsroot/python/dist/src/Tools/ht2html: No such file or directory it used to work... </F>
maybe not the right forum, but I suppose everyone here is using CVS, so...
...could anyone explain why I keep getting this error?
$ cvs -z6 up -P -d ... cvs server: Updating dist/src/Tools/ht2html cvs [server aborted]: cannot open directory /projects/cvsroot/python/dist/src/Tools/ht2html: No such file or directory
it used to work...
EXPLANATION: For some reason that directory existed on the mirror server but not in the master CVS tree repository. It was created once but quickly deleted -- not quickly enough apparently to prevent it to leak to the slave. Then we did a global resync from the master to the mirror and that wiped out the mirror version. Good riddance. FIX: Edit Tools/CVS/Entries and delete the line that mentions ht2html, then do another cvs update. --Guido van Rossum (home page: http://www.python.org/~guido/)
[/F]
...could anyone explain why I keep getting this error?
$ cvs -z6 up -P -d ... cvs server: Updating dist/src/Tools/ht2html cvs [server aborted]: cannot open directory /projects/cvsroot/python/dist/src/Tools/ht2html: No such file or directory
it used to work...
It stopped working a week ago Thursday, and Guido & Barry know about it. The directory in question vanished from the server under mysterious circumstances. You can get going again by deleting the ht2html line in your local Tools/CVS/Entries file.
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/)
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
"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
"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
"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
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
"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
participants (6)
-
Barry A. Warsaw -
Fredrik Lundh -
Guido van Rossum -
Mark Hammond -
Skip Montanaro -
Tim Peters