[Python-Dev] String methods... finally

Tim Peters tim_one at email.msn.com
Sat Jun 12 20:28:13 CEST 1999

[Skip Montanaro]
> Any reason why join should be a builtin and not a method available just
> to sequences?  Would there some valid interpretation of
>     join( {'a': 1} )
>     join( 1 )
> ?  If not, I vote for method-hood, not builtin-hood.

Same here, except as a method we've got it twice backwards <wink>:  it
should be a string method, but a method of the *separator*:


same as

    convert each elt in seq to a string of the same flavor as
    sep, then paste the converted strings together with sep
    between adjacent elements


    " ".join(list)

delivers the same result as today's

    string.join(map(str, list), " ")


    L" ".join(list)

does much the same tomorrow but delivers a Unicode string (or is the "L" for
Lundh string <wink>?).

It looks odd at first, but the more I play with it the more I think it's
"the right thing" to do:  captures everything that's done today, plus the
most common idiom (mapping str first across the sequence) on top of that,
adapts seamlessly (from the user's view) to new string types, and doesn't
invite uselessly redundant generalization to non-sequence types.  One other
attraction perhaps unique to me:  I can never remember whether string.join's
default separator is a blank or a null string!  Explicit is better than
implicit <wink>.

the-heart-of-a-join-is-the-glue-ly y'rs  - tim

More information about the Python-Dev mailing list