Just in case anybody missed it the first several times, there were several inconsistencies in the string methods/functions. This checkin should make everything consistent for 2.3. I'm planning to backport these string changes to 2.2.3. The reason is that methods on string objects already have the changes, only doc is being updated. The string module has the change for strip, but not lstrip/rstrip, and UserString doesn't have any. Modified Files: Doc/lib/libstring.tex: 1.49 Lib/UserString.py: 1.17 Lib/string.py: 1.68 Lib/test/string_tests.py: 1.31 Objects/stringobject.c: 2.208 Objects/unicodeobject.c: 2.187 Log Message: Attempt to make all the various string *strip methods the same. * Doc - add doc for when functions were added * UserString * string object methods * string module functions 'chars' is used for the last parameter everywhere. These changes will be backported, since part of the changes have already been made, but they were inconsistent. Neal
Hi everybody, As this is my first message on this development list I'll introduce myself, I am a hardware designer in a new french startup Arteris which is developping MicroElectronics IP cores. I'm responsible for development of EDA tools, ie software to design and validate hardware designs. For this purpose we've been developping a EDA design plateform enterily in Python (with Python-C parts for the core database) for about 14 months. This plateform is being actively used for about three months and is working well. Now I'd like to give some help in developing Python, using my own experience to try to improve this great language. I'll start simple here, (we've got other great ideas, but i'll expose them here when there will be some kind of first draft). On string objects there is a find and rfind, a lstrip and rstrip, but there is no rsplit function, is there a reason why there isn't, or is this only because nobody implement it ? ( in this case I'll propose a patch in a few days). I'm mainly using it for 'toto.titi.tata'.rsplit('.',1) -> 'toto.titi','tata' as our internal database representation is quite like a logical filesystem. -- Boris Boutillier - boris.boutillier@arteris.net On Fri, 2003-04-11 at 00:50, Neal Norwitz wrote:
Just in case anybody missed it the first several times, there were several inconsistencies in the string methods/functions. This checkin should make everything consistent for 2.3.
I'm planning to backport these string changes to 2.2.3. The reason is that methods on string objects already have the changes, only doc is being updated. The string module has the change for strip, but not lstrip/rstrip, and UserString doesn't have any.
Modified Files:
Doc/lib/libstring.tex: 1.49 Lib/UserString.py: 1.17 Lib/string.py: 1.68 Lib/test/string_tests.py: 1.31 Objects/stringobject.c: 2.208 Objects/unicodeobject.c: 2.187
Log Message:
Attempt to make all the various string *strip methods the same. * Doc - add doc for when functions were added * UserString * string object methods * string module functions 'chars' is used for the last parameter everywhere.
These changes will be backported, since part of the changes have already been made, but they were inconsistent.
Neal
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
On string objects there is a find and rfind, a lstrip and rstrip, but there is no rsplit function, is there a reason why there isn't, or is this only because nobody implement it ? ( in this case I'll propose a patch in a few days). I'm mainly using it for 'toto.titi.tata'.rsplit('.',1) -> 'toto.titi','tata' as our internal database representation is quite like a logical filesystem.
I think the reason is that there isn't enough need for it. The special case of s.rsplit(c, 1) can be coded so easily by using rfind() that I don't see the need to add it. Our Swiss Army Knife string type is beginning to be so loaded with features that I am reluctant to add more. The cost of a new feature these days is measured in the number of books that need to be updated, not the number of lines of code needed to implement it. For your amusement only (! :-), I offer this implementation of rsplit(), which works in Python 2.3: def rsplit(string, sep, count=-1): L = [part[::-1] for part in string[::-1].split(sep[::-1], count)] L.reverse() return L --Guido van Rossum (home page: http://www.python.org/~guido/)
I see, I didn't think about all the documentations to update, and i should have as I've got the same problem in my project :).
I think the reason is that there isn't enough need for it. The special case of s.rsplit(c, 1) can be coded so easily by using rfind() that I don't see the need to add it. Our Swiss Army Knife string type is beginning to be so loaded with features that I am reluctant to add more. The cost of a new feature these days is measured in the number of books that need to be updated, not the number of lines of code needed to implement it.
For your amusement only (! :-), I offer this implementation of rsplit(), which works in Python 2.3:
def rsplit(string, sep, count=-1): L = [part[::-1] for part in string[::-1].split(sep[::-1], count)] L.reverse() return L Didn't thought about this one, tricky and amusing.
-- Boris Boutillier - Boris.Boutillier@arteris.net
participants (3)
-
Boris Boutillier -
Guido van Rossum -
Neal Norwitz