Re: [Python-Dev] Death to string functions!
Barry wrote:
I just did a quick scan through the 1.5.2 library, and _most_ occurrances of string.join() are used with a string constant for the second argument. There is a whole bunch of one-arg string.join()'s, too. Recommending replacing all of these (not to mention all the code "out there") with named constants seems plain silly. Sure, " ".join() is the most "logical" choice for Python as it stands, but it's definitely not the most intuitive, as evidenced by the number of times this comes up on c.l.py: to many people it simply "looks wrong". Maybe this is the deal: joiner.join() makes a whole lot of sense from an _implementation_ standpoint, but a whole lot less as a public interface. It's easy to explain why join() can't be a method of sequences (in Python), but that alone doesn't justify a string method. string.join() is not quite unlike map() and friends: map() wouldn't be so bad as a sequence method, but that isn't practical for exactly the same reasons: so it's a builtin. (And not a function method...) So, making join() a builtin makes a whole lot of sense. Not doing this because people sometimes use a local reference to os.path.join seems awfully backward. Hm, maybe joiner.join() could become a special method: joiner.__join__(), that way other objects could define their own implementation for join(). (Hm, wouldn't be the worst thing for, say, a file path object...) Just
"JvR" == Just van Rossum <just@letterror.com> writes:
JvR> Recommending replacing all of these (not to mention all the JvR> code "out there") with named constants seems plain silly. Until there's a tool to do the migration, I don't (personally) recommend wholesale migration. For new code I write though, I usually do it the way I described (which is intuitive to me, but then so is moving your fingers at a blinding speed up and down 5 long strips of metal to cause low bowel-tickling rumbly noises). JvR> So, making join() a builtin makes a whole lot of sense. Not JvR> doing this because people sometimes use a local reference to JvR> os.path.join seems awfully backward. I agree. Have we agreed on the semantics and signature of builtin join() though? Is it just string.join() stuck in builtins? -Barry
At 12:20 PM -0500 19-12-2000, Barry A. Warsaw wrote:
I agree. Have we agreed on the semantics and signature of builtin join() though? Is it just string.join() stuck in builtins?
Yep. I'm with /F that further generalization can be done later. Oh, does this mean that "".join() becomes deprecated? (Nice test case for the warning framework...) Just
No. --Guido van Rossum (home page: http://www.python.org/~guido/)
At 1:56 PM -0500 19-12-2000, Barry A. Warsaw wrote:
And keep two non-deprecated ways to do the same thing? I'm not saying it should be removed, just that the powers that be declare that _one_ of them is the preferred way. And-if-that-one-isn't-builtin-join()-I-don't-know-why-to-even-bother y'rs -- Just
"JvR" == Just van Rossum <just@letterror.com> writes:
JvR> Recommending replacing all of these (not to mention all the JvR> code "out there") with named constants seems plain silly. Until there's a tool to do the migration, I don't (personally) recommend wholesale migration. For new code I write though, I usually do it the way I described (which is intuitive to me, but then so is moving your fingers at a blinding speed up and down 5 long strips of metal to cause low bowel-tickling rumbly noises). JvR> So, making join() a builtin makes a whole lot of sense. Not JvR> doing this because people sometimes use a local reference to JvR> os.path.join seems awfully backward. I agree. Have we agreed on the semantics and signature of builtin join() though? Is it just string.join() stuck in builtins? -Barry
At 12:20 PM -0500 19-12-2000, Barry A. Warsaw wrote:
I agree. Have we agreed on the semantics and signature of builtin join() though? Is it just string.join() stuck in builtins?
Yep. I'm with /F that further generalization can be done later. Oh, does this mean that "".join() becomes deprecated? (Nice test case for the warning framework...) Just
No. --Guido van Rossum (home page: http://www.python.org/~guido/)
At 1:56 PM -0500 19-12-2000, Barry A. Warsaw wrote:
And keep two non-deprecated ways to do the same thing? I'm not saying it should be removed, just that the powers that be declare that _one_ of them is the preferred way. And-if-that-one-isn't-builtin-join()-I-don't-know-why-to-even-bother y'rs -- Just
participants (4)
-
barry＠digicool.com -
Fredrik Lundh -
Guido van Rossum -
Just van Rossum