I come to praise .join, not to bury it...

[Alex Martelli]

"Greg Ewing" <greg at cosc.canterbury.ac.nz> wrote in message
news:3AA2F4B3.A7496E76 at cosc.canterbury.ac.nz...
> Alex Martelli wrote:
> >
> > I have not heard ANY _technical_ arguments opposed to
> > this last time the discussion went around -- nothing but
> > vague aesthetic, "it should be the other way", "I find it
> > ugly" kind of complaints.
>
> While your arguments are _technically_ sound, we are yet
> to be convinced that the benefits outweigh the drawbacks
> of being forced to use what many find to be an obscure and
> hard-to-follow syntax for all string joining.

Note that there is no 'forcing': once the right polymorphic
architecture has been chosen, one can still choose HIDE the
fact that polymorphism is happening behind a function call --
and, indeed, the string module supplies ready-made versions
of such calls (for backwards compatibility reasons, no doubt,
but, as a side effect, you can use it 'aesthetically'...!):

def replace(s, old, new, maxsplit=-1):
    return s.replace(old, new, maxsplit)

and so on, and so forth.  Personally, I prefer not to hide
such things (explicit better than implicit), but, you refined
aesthetes are being positively _pampered_ here -- a whole
module's worth of such syntax-sugar-providing functions...!


When you choose the right underlying architecture, the one
that best matches the actual needs, you MAY later decide to
'paper it over' with syntax-sugary superstructures if your
aesthetics so dictate -- since I am an engineer, I'm sure you
can guess what my attitude might be to such aesthetics, but
that's a different flamewar ("form follows function" crusaders,
this IS a call to arms!-).

The key point is that the actual *function* (the one which
I strongly opine 'form' should follow -- while acknowledging
the widespread human foible for 'dressing it up' in trompe
l'oeil 'prettiness':-) for joining IS: polymorphism on the
joiner object, access through standard sequence interface
for the sequence whose items are to be joined.

As long as that '_technically_ sound' architecture is the
underlying one (as, fortunately!, it is in Python 2), the
amount of actual damage you can do by covering it in your
chosen stucco and/or wallpaper is reasonably limited.

IF the underlying architecture did NOT reflect actual needs
(e.g., if the string.join function had to typeswitch on the
joiner-object to distinguish Unicode from single-byte --
and *every other* string module function had to similarly
typeswitch, rather than each being able to just delegate
to string-object's modules!), _then_ we'd be in deep doodoo.
But, fortunately, Python continued its tradition of pretty
good design indeed, introducing string methods in Python 2.


> The vast majority of string-joining operations in Python
> code that I've seen and written haven't had any need for
> polymorphism at all.

I guess you feel no need for Unicode -- what's the rest of
the world after all, we KNOW that all things that matter
only happen in countries where good ol' ASCII is quite
adequate for all of our string needs, right?


Alex