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

[Greg Ewing]

Alex Martelli wrote:
> 
> The joiner-dispatch DESIGN *affords* efficiency gains;

I still don't see how. You have to dispatch on all the
arguments eventually somehow, whether by typeswitch or
something else.

> And *WHAT* 'standard interface' would apply on the joiner
> object, pray?

The same one that applies to all the strings being
joined, i.e. "make yourself into a string". Yes, yes,
I KNOW you want your joiner object to be able to be
not just a simple string but some esoteric entity
capable of doing anything it wants to any sequence
of anything at all. But I don't feel any great desire
for that whatsoever. I'm quite happy with the current
highly specialised special-case-the-snot-out-of-joining-
these-strings meaning of 'join'. And the new design is
no better at achieving *that*, as far as I can see.

It's just occurred to me that there may be some
natural-language ambiguity here in the use of the
term "joiner". To me, it's not "the joiner" in the
active sense of "the object which performs the 
computation of joining", but the passive sense of
"the object which ends up being in between the
other strings".

In other words, it's the difference between "pipe
joiner" being a person who carries out plumbing work,
and a short piece of pipe with threads in each end.

> 'Counting' technical advantages is as idiotic as 'counting'
> coins as a measure of wealth

Sure it is, but the point is that blindly ranking all 
technical considerations above all aesthetic ones is
just as silly. Otherwise we might as well all switch
to Perl, which I hear is faster at reading files. :-)

>     'comma-separate these values'

You do have a point there, sort of, but it still sounds
more terse and cryptic than "separate these values with
commas", and crypticness is generally not valued much
in the Python culture. Also, I don't normally think of
the '.' operator as corresponding to a hyphen used that
way in English. The Python translation of that to my
mind would be

   comma_separate(these_values)

and not

   comma.separate(these_values)

which to me means either "comma, separate these values" 
or "separate this comma with these values". The former
is slightly odd because I'm not used to giving commands
to punctuation symbols, and the latter is just plain...
what can I say... BACKWARDS! (Yes, there's that word
again.)

> (Please note that the CSV acronym IS an English one

Also interesting to note that it's *not* CJV. Even
in English, "comma-join these values" sounds strange,
to my ears, anyway. We regularly talk about commas as
being separators, but hardly ever as joiners. 

If I were putting "-" between things, I might 
say it was a joiner rather than a separator. But even
then I wouldn't say "hyphen-join these values", I'd
say "hyphenate these values".

> The string object and the string module are both in
> the Python core, so moving functionality between them
> can in no way be considered 'bloating'.

Not bloating the core, bloating the string object.

The string module may be statically linked in by
default, but it could be dynamically linked, or omitted
altogether, just by changing the config file. Chances
are I'll never want to do that, but it's nice to know
that I *could*. I couldn't cut out all the non-essential
parts of the string object so easily.

I like the idea of objects that concentrate on doing one
job and doing it well. In the case of strings, that
job is being a repository of characters, not being something
that can do everything you can think of that you might
possibly want to do to some characters.

Yes, that's an aesthetic consideration, but I don't
think you can separate technical and aesthetic considerations
completely. How much weight you give to a given technical
advantage (such as modularity of the core features) is
an aesthetic judgement.

-- 
Greg Ewing, Computer Science Dept, University of Canterbury,	  
Christchurch, New Zealand
To get my email address, please visit my web page:	  
http://www.cosc.canterbury.ac.nz/~greg