Magnus Lie Hetland wrote:
>
> Aahz Maruch <aahz@netcom.com> wrote in message
> news:8fh9ki$51h$1@slb3.atl.mindspring.net...
> > In article <rhgmhs07ulsob3pptd6eh4f2ag4qj911bj@4ax.com>,
> > Ben Wolfson <rumjuggler@cryptarchy.org> wrote:
> > >
> > >', '.join(['foo', 'bar', 'baz'])
> >
> > This only works in Python 1.6, which is only released as an alpha at
> > this point. I suggest rather strongly that we avoid 1.6-specific idioms
> > until 1.6 gets released, particularly in relation to FAQ-type questions.
>
> This is indeed a bit strange IMO... If I were to join the elements of a
> list I would rather ask the list to do it than some string... I.e.
>
> ['foo', 'bar', 'baz'].join(', ')
>
> (...although it is the string that joins the elements in the resulting
> string...)
I believe the notation of "everything is an object, and objects
provide all their functionality" is a bit stressed in Python 1.6 .
The above example touches the limits where I'd just say
"OO isn't always the right thing, and always OO is the wrong thing".
A clear advantage of 1.6's string methods is that much code
becomes shorter and easier to read, since the nesting level
of braces is reduced quite much. The notation also appears to be
more in the order of which actions are actually processed.
The split/join issue is really on the edge where I begin to not
like it.
It is clear that the join method *must* be performed as a method
of the joining character, since the method expects a list as its
argument. It doesn't make sense to use a list method, since
lists have nothing to do with strings.
Furthermore, the argument to join can be any sequence. Adding
a join method to any sequence, just since we want to join some
strings would be overkill.
So the " ".join(seq) notation is the only possible compromise,
IMHO.
It is actually arguable if this is still "Pythonic".
What you want is to join a list of string by some other string.
This is neither a natural method of the list, nor of the joining
string in the first place.
If it came to the point where the string module had some extra
methods which operate on two lists of string perhaps, we would
have been totally lost, and enforcing some OO method to support
it would be completely off the road.
Already a little strange is that the most string methods
return new objects all the time, since strings are immutable.
join is of really extreme design, and compared with other
string functions which became more readable, I think it is
counter-intuitive and not the way people are thinking.
The think "I want to join this list by this string".
Furthermore, you still have to import string, in order to use
its constants.
Instead of using a module with constants and functions, we
now always have to refer to instances and use their methods.
It has some benefits in simple cases.
But if there are a number of different objects handled
by a function, I think enforcing it to be a method of
one of the objects is the wrong way, OO overdone.
doing-OO-only-if-it-looks-natural-ly y'rs - chris
--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
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