[Python-checkins] CVS: python/dist/src/Lib string.py,1.46,1.47

[bjorn]

I seem to have hit a sore point for Frederik, for which I'm sorry.  However, I
still think my points are valid.

Fredrik Lundh wrote:

> listen very carefully:
>
>     PYTHON IS BASED ON INTERFACES, NOT ON
>     STRICT INHERITANCE.  *ANY* OBJECT THAT
>     IMPLEMENTS TWO WELL-DEFINED METHODS
>     CAN BE USED AS A SEQUENCE OBJECT.

Having a SequenceType base class that contains common behavior is an
implementation detail only.  There is of course nothing wrong with duplicating
the functionality in all classes that implement the SequenceType interface,
however that clearly indicates that there should be implementation sharing and
not just interface sharing.  In any case, there is nothing stopping objects that
do not inherit from the "SequenceClass" to implement the required interface and
be just as usable as today.

> maybe we should change this?  let's see:
>
>     "btw, now that you've installed 1.6, your old sequence
>     classes no longer work.  you have to make sure they all
>     inherit from AbstractSequence.  if you're using C types,
>     you're SOL"
>
> really?

this is just plain silly. See above.

> > -- while join can be *defined* as a series of concatenations,
> >    *implementing* things that way doesn't work in real life.  do
> >    you really think that *all* sequence objects should know
> >    how to join all possible string types in an efficient way?  or
> >    is that better left to the string implementation?
> >
> > Conversely, to you really think that both string classes should know how
> to
> > efficiently join all possible sequence types?
>
> yes, because all they have to do is to use the abstract
> sequence interface:
> http://www.python.org/doc/current/api/abstract.html
>
> > Consider:
> >
> >     class MyTree:
> >         def join(sep=''):
> >             lhs = rhs = ''
> >             if self.lhs:
> >                 lhs = self.join(self.lhs)
> >             if self.rhs:
> >                 rhs = self.join(self.rhs)
> >             # presumably the + operator would do any neccessary coercion?
> >             return lhs + sep + self.data + sep + rhs
> >
> > sometimes implementing join as a series of concatenations does work
>
> only if you don't give a damn about performance...
>
>     "btw, now that you've installed 1.6, string.join is
>     slow as hell.  you might as well use reduce"
>
> forget it.  won't happen.
>
> </F>

you seem to be arguing both sides of the fence here. On the one hand you want
performance, on the other hand you want the sequence interface, yet you fail to
deal with my statement that there is no efficient way of implementing the
sequence interface for the MyTree example. (and yes, we both know that there are
efficient means of doing it, they're just far from trivial and shouldn't be
required.)

Also, I don't understand your argument that ['a', 'b', 'c'].join() would be
slow.  It shouldn't be any harder to implement that in C, than implementing
''.join(['a', 'b', 'c']).  The point is that with join attached to the sequence
object, it would be no slower than the __getitem__/sequence interface
implementation, but could conceivably be much faster. It all depends on the
container. (think along the lines of MyTree implemented in C)

This issue might be moot though, since a quick survey of Python programmers
here, showed that while they really disliked ''.join(['a', 'b', 'c']), they
didn't particularly enjoy ['a', 'b', 'c'].join() either, and were probably going
to continue using string.join(['a', 'b', 'c']).

-- bjorn