PEP 4 says # Usage of a module may be `deprecated', which means that it may be # removed from a future Python release. Proposals for better wording are welcome (and yes, I still have to get the comments that I got into the document). Regards, Martin
So I was thinking about this whole thing, and wondering why it was that seeing things like: " ".join(aList) bugged me to no end, while: aString.lower() didn't seem to look wrong. I finally put my finger on it, and I haven't seen anyone mention it, so I guess I'll do so. To me, the concept of "join" on a string is just not quite kosher, instead it should be something like this: aList.join(" ") or if you want it without the indirection: ['item', 'item', 'item'].join(" ") Now *THAT* looks right to me. The example of a join method on a string just doesn't quite gel in my head, and I did some thinking and digging, and well, when I pulled up my Smalltalk browser, things like join are done on Collections, not on Strings. You're joining the collection, not the string. Perhaps in a rush to move some things that were "string related" in the string module into methods on the strings themselves (something I whole-heartedly support), we moved a few too many things there---things that symantically don't really belong as methods on a string object. How this gets resolved, I don't know... but I know a lot of people have looked at the string methods---and they each keep coming back to 1 or 2 that bug them... and I think it's those that really aren't methods of a string, but instead something that operates with strings, but expects other things. Chris -- | Christopher Petrilli | petrilli@amber.org
Boy, are you stirring up a can of worms that we've been through many times before! Nothing you say hasn't been said at least a hundred times before, on this list as well as on c.l.py. The problem is that if you want to make this a method on lists, you'll also have to make it a method on tuples, and on arrays, and on NumPy arrays, and on any user-defined type that implements the sequence protocol... That's just not reasonable to expect. There really seem to be only two possibilities that don't have this problem: (1) make it a built-in, or (2) make it a method on strings. We chose for (2) for uniformity, and to avoid the potention with os.path.join(), which is sometimes imported as a local. If " ".join(L) bugs you, try this: space = " " # This could be a global . . . s = space.join(L) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido:
And I'll wager you'll continue to hear them said at regular intervals for a long time to come, because you've done something which a lot of people feel very strongly was a mistake, and they have some very rational arguments as to why it was a mistake, whereas you don't seem to have any arguments to the contrary which those people are likely to find convincing.
There really seem to be only two possibilities that don't have this problem: (1) make it a built-in, or (2) make it a method on strings.
False dichotomy. Some other possibilities: (3) Use an operator. (4) Leave it in the string module! Really, I don't see what would be so bad about that. You still need somewhere to put all the string-related constants, so why not keep the string module for those, plus the few functions that don't have any other obvious place?
Surely you must realise that this completely fails to address Mr. Petrilli's concern? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
[Guido]
[Greg Ewing]
Then it's a wash: Guido doesn't find their arguments convincing either, and ties favor the status quo even in the absence of BDFLness.
There really seem to be only two possibilities that don't have this problem: (1) make it a built-in, or (2) make it a method on strings.
False dichotomy. Some other possibilities:
(3) Use an operator.
Oh, that's likely <wink>.
Guido said he wants to deprecate the entire string module, so that Python can eventually warn on the mere presence of "import string". That's what he said when I earlier ranted in favor of keeping the string module around. My guess is that making it a builtin is the only alternative that stands any chance at this point.
Surely you must realise that this completely fails to address Mr. Petrilli's concern?
Don't know about Guido, but I don't realize that, and we haven't heard back from Charles. His objections were raised the first day " ".join was suggested, space.join was suggested almost immediately after, and that latter suggestion did seem to pacify at least several objectors. Don't know whether it makes Charles happier, but since it *has* made others happier in the past, it's not unreasonable to imagine that Charles might like it too. if-we're-to-be-swayed-by-his-continued-outrage-afraid-it-will- have-to-come-from-him-ly y'rs - tim
"CP" == Christopher Petrilli <petrilli@amber.org> writes:
CP> So I was thinking about this whole thing, and wondering why it CP> was that seeing things like: CP> " ".join(aList) CP> bugged me to no end, while: CP> aString.lower() CP> didn't seem to look wrong. I finally put my finger on it, and CP> I haven't seen anyone mention it, so I guess I'll do so. Actually, it has been debated to death. ;) This looks better: SPACE = ' ' SPACE.join(aList) That reads good to me ("space-join this list") and that's how I always write it. That said, there are certainly lots of people who agree with you. You can't put join() on sequences though, until you have builtin base-classes, or interfaces, or protocols or some such construct, because otherwise you'd have to add it to EVERY sequence, including classes that act like sequences. One idea that I believe has merit is to consider adding join() to the builtins, probably with a signature like: join(aList, aString) -> aString This horse has been whacked pretty good too, but I don't remember seeing a patch or a pronouncement. -Barry
So I was thinking about this whole thing, and wondering why it was that seeing things like: " ".join(aList) bugged me to no end, while: aString.lower() didn't seem to look wrong. I finally put my finger on it, and I haven't seen anyone mention it, so I guess I'll do so. To me, the concept of "join" on a string is just not quite kosher, instead it should be something like this: aList.join(" ") or if you want it without the indirection: ['item', 'item', 'item'].join(" ") Now *THAT* looks right to me. The example of a join method on a string just doesn't quite gel in my head, and I did some thinking and digging, and well, when I pulled up my Smalltalk browser, things like join are done on Collections, not on Strings. You're joining the collection, not the string. Perhaps in a rush to move some things that were "string related" in the string module into methods on the strings themselves (something I whole-heartedly support), we moved a few too many things there---things that symantically don't really belong as methods on a string object. How this gets resolved, I don't know... but I know a lot of people have looked at the string methods---and they each keep coming back to 1 or 2 that bug them... and I think it's those that really aren't methods of a string, but instead something that operates with strings, but expects other things. Chris -- | Christopher Petrilli | petrilli@amber.org
Boy, are you stirring up a can of worms that we've been through many times before! Nothing you say hasn't been said at least a hundred times before, on this list as well as on c.l.py. The problem is that if you want to make this a method on lists, you'll also have to make it a method on tuples, and on arrays, and on NumPy arrays, and on any user-defined type that implements the sequence protocol... That's just not reasonable to expect. There really seem to be only two possibilities that don't have this problem: (1) make it a built-in, or (2) make it a method on strings. We chose for (2) for uniformity, and to avoid the potention with os.path.join(), which is sometimes imported as a local. If " ".join(L) bugs you, try this: space = " " # This could be a global . . . s = space.join(L) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido:
And I'll wager you'll continue to hear them said at regular intervals for a long time to come, because you've done something which a lot of people feel very strongly was a mistake, and they have some very rational arguments as to why it was a mistake, whereas you don't seem to have any arguments to the contrary which those people are likely to find convincing.
There really seem to be only two possibilities that don't have this problem: (1) make it a built-in, or (2) make it a method on strings.
False dichotomy. Some other possibilities: (3) Use an operator. (4) Leave it in the string module! Really, I don't see what would be so bad about that. You still need somewhere to put all the string-related constants, so why not keep the string module for those, plus the few functions that don't have any other obvious place?
Surely you must realise that this completely fails to address Mr. Petrilli's concern? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
[Guido]
[Greg Ewing]
Then it's a wash: Guido doesn't find their arguments convincing either, and ties favor the status quo even in the absence of BDFLness.
There really seem to be only two possibilities that don't have this problem: (1) make it a built-in, or (2) make it a method on strings.
False dichotomy. Some other possibilities:
(3) Use an operator.
Oh, that's likely <wink>.
Guido said he wants to deprecate the entire string module, so that Python can eventually warn on the mere presence of "import string". That's what he said when I earlier ranted in favor of keeping the string module around. My guess is that making it a builtin is the only alternative that stands any chance at this point.
Surely you must realise that this completely fails to address Mr. Petrilli's concern?
Don't know about Guido, but I don't realize that, and we haven't heard back from Charles. His objections were raised the first day " ".join was suggested, space.join was suggested almost immediately after, and that latter suggestion did seem to pacify at least several objectors. Don't know whether it makes Charles happier, but since it *has* made others happier in the past, it's not unreasonable to imagine that Charles might like it too. if-we're-to-be-swayed-by-his-continued-outrage-afraid-it-will- have-to-come-from-him-ly y'rs - tim
"CP" == Christopher Petrilli <petrilli@amber.org> writes:
CP> So I was thinking about this whole thing, and wondering why it CP> was that seeing things like: CP> " ".join(aList) CP> bugged me to no end, while: CP> aString.lower() CP> didn't seem to look wrong. I finally put my finger on it, and CP> I haven't seen anyone mention it, so I guess I'll do so. Actually, it has been debated to death. ;) This looks better: SPACE = ' ' SPACE.join(aList) That reads good to me ("space-join this list") and that's how I always write it. That said, there are certainly lots of people who agree with you. You can't put join() on sequences though, until you have builtin base-classes, or interfaces, or protocols or some such construct, because otherwise you'd have to add it to EVERY sequence, including classes that act like sequences. One idea that I believe has merit is to consider adding join() to the builtins, probably with a signature like: join(aList, aString) -> aString This horse has been whacked pretty good too, but I don't remember seeing a patch or a pronouncement. -Barry
participants (7)
-
barry＠digicool.com -
Christopher Petrilli -
Fredrik Lundh -
Greg Ewing -
Guido van Rossum -
Martin v. Loewis -
Tim Peters