Coding standard: Prefixing variables to indicate datatype
tjreedy at udel.edu
Mon Jan 20 18:25:11 CET 2003
"Erik Max Francis" <max at alcyone.com> wrote in message
news:3E2BB957.2A2199CF at alcyone.com...
> Martin Maney wrote:
> > Jp Calderone <exarkun at intarweb.us> wrote:
> > > ("a", "b", "c").join(" ") might make sense, but it would also
> > > involve
> > > writing a pile more code, and reducing the usefulness of the
> > > operation.
> > How does that reduce the usefulness? Seems to me that it would
> > the restoration of the small conveninence of having a default
> > separator, as string.join() did.
> Setting aside for the moment this wasn't what the original poster
> talking about, the problem with a join method in every sequence is
> that: It would have to be in _every_ sequence. Not just lists,
> (even strings) but user defined types as well.
And, as I pointed out before, but keeps getting ignored, dicts,
generators, iterators, and indeed *any* iteratable. To repeat two of
my previous examples:
>>> from __future__ import generators
>>> def g():
... for i in range(5): yield str(i)
The new (2.2) iterable concept is extremely powerful, more so than
some seem to realize. Add a simple interface to an object, almost any
object, which does not have to be a sequence but merely seqeunceable,
and you can plug it into thousands of specific functions and methods.
But its usefulness depends on the iterator interface being kept very
simple: .__iter__() and .next().
> Taking this approach to its logical conclusion, you rapidly get a
> of kitchensinkitis where _every_ sequence has to implement a huge
> plethora of methods, or nothing's guaranteed to work. That's the
> way around.
> Besides, if you don't like the syntax of JOINER.join(SEQUENCE), you
> always just use the string.join(SEQUENCE, JOINER) function.
or, as I also showed before, str.join(joiner, sequence), which does
require a joiner, but saves an import and 3 chars as compensation.
Take your choice.
Terry J. Reedy
More information about the Python-list