Mailing List Archive

>>>>> "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

> The only reason for making it a builtin would be to avoid pulling in
> all of string just to get join.

another reason is that you might be able to avoid
a unicode module...

</F>