Barry wrote:
>Actually, it has been debated to death. ;) This looks better:
>
> SPACE = ' '
> SPACE.join(aList)
>
>That reads good to me ("space-join this list") and that's how I always
>write it.
I just did a quick scan through the 1.5.2 library, and _most_
occurrances of string.join() are used with a string constant
for the second argument. There is a whole bunch of one-arg
string.join()'s, too. Recommending replacing all of these (not
to mention all the code "out there") with named constants seems
plain silly.
Sure, " ".join() is the most "logical" choice for Python as it
stands, but it's definitely not the most intuitive, as evidenced
by the number of times this comes up on c.l.py: to many people
it simply "looks wrong". Maybe this is the deal: joiner.join()
makes a whole lot of sense from an _implementation_ standpoint,
but a whole lot less as a public interface.
It's easy to explain why join() can't be a method of sequences
(in Python), but that alone doesn't justify a string method.
string.join() is not quite unlike map() and friends:
map() wouldn't be so bad as a sequence method, but that isn't
practical for exactly the same reasons: so it's a builtin.
(And not a function method...)
So, making join() a builtin makes a whole lot of sense. Not
doing this because people sometimes use a local reference to
os.path.join seems awfully backward. Hm, maybe joiner.join()
could become a special method: joiner.__join__(), that way
other objects could define their own implementation for
join(). (Hm, wouldn't be the worst thing for, say, a file
path object...)
Just
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