[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*:
sep.join(seq)
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
So
" ".join(list)
delivers the same result as today's
string.join(map(str, list), " ")
and
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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4