Given the heat in this discussion, I'm not sure if I endorse *any* of the proposals so far any more... How would Java do this? A static function in the String class, probably. The Python equivalent is... A function in the string module. So maybe string.join() it remains. --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido" == Guido van Rossum <guido@cnri.reston.va.us> writes:
Guido> Given the heat in this discussion, I'm not sure if I Guido> endorse *any* of the proposals so far any more... Oh I dunno. David and I aren't throwing rocks at each other yet :) Guido> How would Java do this? A static function in the String Guido> class, probably. The Python equivalent is... A function Guido> in the string module. So maybe string.join() it remains. The only reason for making it a builtin would be to avoid pulling in all of string just to get join. But I guess we need to get some more experience using the methods before we know whether this is a real problem or not. as-good-as-a-from-string-import-join-and-easier-to-implement-ly y'rs, -Barry
BAW> The only reason for making it a builtin would be to avoid pulling BAW> in all of string just to get join. I still don't understand the motivation for making it a builtin instead of a method of the types it operates on. Making it a builtin seems very un-object-oriented to me. Skip
I still don't understand the motivation for making it a builtin instead of a method of the types it operates on. Making it a builtin seems very un-object-oriented to me.
Because if you make it a method, every sequence type needs to know about joining strings. (This wouldn't be a problem in Smalltalk where sequence types inherit this stuff from an abstract sequence class, but in Python unfortunately that doesn't exist.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, 11 Jun 1999, Guido van Rossum wrote:
I still don't understand the motivation for making it a builtin instead of a method of the types it operates on. Making it a builtin seems very un-object-oriented to me.
Because if you make it a method, every sequence type needs to know about joining strings.
It still seems to me that we could do something like F/'s proposal, where sequences can define a join() method, which could be optimized if the first element is a string to do what string.join, by placing the class method in an instance method of strings, since string joining clearly has to involve at least one string. Pseudocode: class SequenceType: def join(self, separator=None): if hasattr(self[0], '__join__') # covers all types which can be efficiently joined if homogeneous return self[0].__join__(self, separator) # for the rest: if separator is None: return map(operator.add, self) result = self[0] for element in self[1:]: result = result + separator + element return result where the above would have to be done in abstract.c, with error handling, etc. and with strings (regular and unicode) defining efficient __join__'s as in: class StringType: def join(self, separator): raise AttributeError, ... def __join__(self, sequence): return string.join(sequence) # obviously not literally that =) class UnicodeStringType: def __join__(self, sequence): return unicode.join(sequence) (in C, of course). Yes, it's strange to fake class methods with instance methods, but it's been done before =). Yes, this means expanding what it means to "be a sequence" -- is that impossible without breaking lots of code? --david
On Fri, 11 Jun 1999, Skip Montanaro wrote:
BAW> The only reason for making it a builtin would be to avoid pulling BAW> in all of string just to get join.
I still don't understand the motivation for making it a builtin instead of a method of the types it operates on. Making it a builtin seems very un-object-oriented to me.
Builtin-hood makes it possible for one method to apply to many types (or a heterogeneous list of things). I think i'd support the def join(list, sep=None): if sep is None: result = list[0] for item in list[1:]: result = result + item else: result = list[0] for item in list[1:]: result = result + sep + item idea, basically a reduce(operator.add...) with an optional separator -- *except* my main issue would be to make sure that the actual implementation optimizes the case of joining a list of strings. string.join() currently seems like the last refuge for those wanting to avoid O(n^2) time when assembling many small pieces in string buffers, and i don't want it to see it go away. !ping
participants (6)
-
Barry A. Warsaw -
David Ascher -
Fredrik Lundh -
Guido van Rossum -
Ka-Ping Yee -
Skip Montanaro