Curious comment in some old libraries
Pursuant to a conversation Guido and I had in New York, I have gone through and converted the Python library code to use string methods wherever possible, removing a whole boatload of "import string" statements in the process.
(This is one of those times when it's a really, *really* good thing that most modules have an attached self-test. I supplied a couple of these where they were lacking, and improved several of the existing test jigs.)
One side-effect of the change is that nothing in the library uses splitfields or joinfields anymore. But in the process I found a curious contradiction:
stringold.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! stringold.py: (split and splitfields are synonymous) stringold.py:splitfields = split string.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! string.py: (split and splitfields are synonymous) string.py:splitfields = split
It certainly looks to me as though the "NB" comment is out of date. Is there some subtle and wicked reason it has not been removed?
Eric S. Raymond writes:
string.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! string.py: (split and splitfields are synonymous) string.py:splitfields = split
It certainly looks to me as though the "NB" comment is out of date. Is there some subtle and wicked reason it has not been removed?
The comment is correct. splitfields(s) is synonymous with split(s), and splitfields(s, ' ') is synonymous with split(s, ' '). If the second arg is omitted, any stretch of whitespace is used as the separator, but if ' ' is supplied, exactly one space is used to split fields. split(s, None) is synonymous with split(s), splitfields(s), and splitfields(s, None).
-Fred
On Fri, Feb 09, 2001 at 03:03:29PM -0500, Eric S. Raymond wrote:
Pursuant to a conversation Guido and I had in New York, I have gone through string.py:# NB: split(s) is NOT the same as splitfields(s, ' ')!
It certainly looks to me as though the "NB" comment is out of date. Is there some subtle and wicked reason it has not been removed?
Actually I think it's correct:
import string string.split('a b c')
['a', 'b', 'c']
string.split('a b c', ' ')
['a', '', 'b', 'c']
With no separator, it splits on runs of whitespace. With an explicit separator, it splits on *exactly* that separator.
--amk
Pursuant to a conversation Guido and I had in New York, I have gone through and converted the Python library code to use string methods wherever possible, removing a whole boatload of "import string" statements in the process.
(But note that I didn't ask you to go ahead and do it. Last time when I started doing this I got quite a few comments from python-dev readers who thought it was a bad idea, so I backed off. It's up to you to convince them now. :-)
(This is one of those times when it's a really, *really* good thing that most modules have an attached self-test. I supplied a couple of these where they were lacking, and improved several of the existing test jigs.)
Excellent!
One side-effect of the change is that nothing in the library uses splitfields or joinfields anymore. But in the process I found a curious contradiction:
stringold.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! stringold.py: (split and splitfields are synonymous) stringold.py:splitfields = split string.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! string.py: (split and splitfields are synonymous) string.py:splitfields = split
It certainly looks to me as though the "NB" comment is out of date. Is there some subtle and wicked reason it has not been removed?
Well, split and splitfields really *are* synonymous, but split(s, ' ') is *not* the same as split(s). The latter is the same as split(s, None) which splits on stretches of arbitrary whitespace and ignores leading and trailing whitespace.
So the NB is still true...
--Guido van Rossum (home page: http://www.python.org/~guido/)
"ESR" == Eric S Raymond esr@thyrsus.com writes:
ESR> It certainly looks to me as though the "NB" comment is out of ESR> date. Is there some subtle and wicked reason it has not been ESR> removed?
Look at stropmodule.c. split and splitfields have been identical at least since 08-Aug-1996. :)
-------------------- snip snip -------------------- revision 2.23 date: 1996/08/08 19:16:15; author: guido; state: Exp; lines: +93 -17 Added lstrip() and rstrip(). Extended split() (and hence splitfields(), which is the same function) to support an optional third parameter giving the maximum number of delimiters to parse. -------------------- snip snip --------------------
-Barry
[Eric S. Raymond]
... But in the process I found a curious contradiction:
stringold.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! stringold.py: (split and splitfields are synonymous) stringold.py:splitfields = split string.py:# NB: split(s) is NOT the same as splitfields(s, ' ')! string.py: (split and splitfields are synonymous) string.py:splitfields = split
It certainly looks to me as though the "NB" comment is out of date. Is there some subtle and wicked reason it has not been removed?
It's 100% accurate, but 99% misleading. Plain 100% accurate would be:
# NB: split(s) is NOT the same as split(s, ' '). # And, by the way, since split is the same as splitfields, # it follows that # split(s) is NOT the same as splitfields(s, ' '). # either.
Even better is to get rid of the NB comments, so I just did that. Thanks for pointing it out!
guido wrote:
(But note that I didn't ask you to go ahead and do it. Last time when I started doing this I got quite a few comments from python-dev readers who thought it was a bad idea, so I backed off. It's up to you to convince them now. :-)
footnote: SRE is designed to work (and is being used) under 1.5.2. since I'd rather not maintain two separate versions, I hope it's okay to back out of some of eric's changes...
Cheers /F
footnote: SRE is designed to work (and is being used) under 1.5.2. since I'd rather not maintain two separate versions, I hope it's okay to back out of some of eric's changes...
Fine. Please add a comment to the "import string" statement to explain this!
--Guido van Rossum (home page: http://www.python.org/~guido/)
Fredrik Lundh fredrik@effbot.org:
footnote: SRE is designed to work (and is being used) under 1.5.2. since I'd rather not maintain two separate versions, I hope it's okay to back out of some of eric's changes...
Not a problem for me.
Guido van Rossum guido@digicool.com:
(But note that I didn't ask you to go ahead and do it. Last time when I started doing this I got quite a few comments from python-dev readers who thought it was a bad idea, so I backed off. It's up to you to convince them now. :-)
I'd forgotten that discussion. But, as a general comment...
Propaganda of the deed, Guido. Sometimes this crew is too reflexively conservative for my taste. I have a repertoire of different responses when my desire to make progress collides with such conservatism; one of them, when I don't see substantive objections and believe I can deal with the political fallout more easily than living with the technical problem, is to just freakin' go ahead and *do* it.
This makes some people nervous. That's OK with me -- I'd rather be seen as a bit of a loose cannon than just another lump of inertia. (If nothing else, I find the primate-territoriality reactions I get from the people I occasionally piss off entertaining to watch.) I pick my shots carefully, however, and as a result people usually conclude after the fact that this week's cowboy maneuver was a good thing even if they were a touch irritated with me at the time.
In the particular case of the string-method cleanup, I did get the impression in New York that you wanted to attack this problem but for some reason felt you could not. I am strongly predisposed to be <laughter mode="mad-scientist">helpful</laughter> in such situations, and let the chips fall where they may.
So try not to be surprised if I do more stuff like this -- in fact, if you really don't want me to go cowboy on you occasionally you probably shouldn't talk about your wish-list in my presence.
On the other hand, feel very free to reverse me and slap me down if I pull something that oversteps the bounds of prudence or politeness. Firstly, I'm not thin-skinned that way; nobody with my working style can afford to be. Secondly, as the BDFL you have both the right and the responsibility to rein me in; if I weren't cool with that I wouldn't be here.
(This is one of those times when it's a really, *really* good thing that most modules have an attached self-test. I supplied a couple of these where they were lacking, and improved several of the existing test jigs.)
Excellent!
One of the possible futures I see for myself in this group, if both of the library PEPs you and I have contemplated go through and become policy, is as Keeper Of The Libraries analogously to the way that Fred Drake is Keeper Of The Documentation. I would enjoy this role; if I grow into it, you can expect to see me do a lot more active maintainence of this kind.
There's another level to this that I should try to explain...among the known hazards of being an international celebrity and famously successful project lead is that one can start to believe one is too good to do ordinary work. In order to prevent myself from become bogotified in this way, I try to have at least project going at all times in which I am a core contributor but *not* the top banana. And I deliberately look for a stable to muck out occasionally, as I did last night and as I would do on a larger scale if I were the library keeper.
Python looks like being my `follower' project for the foreseeable future. Take that as a compliment, Guido, because it is meant as one both professionally and personally. This crew may be (probably is) the most tasteful, talented and mature development group I have ever had the privilege to work with. I still rue the fact that I couldn't get you guys to come work for VA...
Eric S. Raymond writes:
of them, when I don't see substantive objections and believe I can deal with the political fallout more easily than living with the technical problem, is to just freakin' go ahead and *do* it.
I think this was the right thing to do in this case. A slap on the back for you!
One of the possible futures I see for myself in this group, if both of the library PEPs you and I have contemplated go through and become policy, is as Keeper Of The Libraries analogously to the way that Fred
You haven't developed the right attitude, then: my self-granted title for this aspect of my efforts is "Documentation Tsar" -- and I don't mind exercising editorial control with my attitude firmly in place! ;-)
Python looks like being my `follower' project for the foreseeable future. Take that as a compliment, Guido, because it is meant as one both professionally and personally. This crew may be (probably is) the most tasteful, talented and mature development group I have ever
Thank you! That's a real compliment for all of us.
had the privilege to work with. I still rue the fact that I couldn't get you guys to come work for VA...
You & others from VA came mighty close!
-Fred
Fine Eric. Thanks for the compliment! In this particular case, I believe that the resistance was more against any official indication that the string module would become obsolete, than against making the changes in the standard library. It was just deemed too much work to make the changes, and because string wasn't going to be obsolete soon, there was little motivation. I'm glad your manic episode took care of that. :-)
In general, though, I must ask you to err on the careful side when the possibility of breaking existing code exists. You can apply the cowboy approach to discussions as well as to coding!
Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs!
Hey, finally a signature quote someone from the Netherlands wouldn't find offensive!
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum guido@digicool.com:
In general, though, I must ask you to err on the careful side when the possibility of breaking existing code exists.
I try to. You notice I haven't committed any changes to the interpreter core. This is a good example of what I mean by picking my shots carefully...
participants (8)
-
Andrew Kuchling -
barry＠digicool.com -
Eric S. Raymond -
Fred L. Drake, Jr. -
Fredrik Lundh -
Guido van Rossum -
Thomas Heller -
Tim Peters