computing with characters

[George Sakkis]

On May 1, 3:36 am, Duncan Booth <duncan.bo... at invalid.invalid> wrote:

> George Sakkis <george.sak... at gmail.com> wrote:
> > On Apr 30, 5:06 am, Torsten Bronger <bron... at physik.rwth-aachen.de>
> > wrote:
> >> Hallöchen!
>
> >> SL writes:
> >> > "Gabriel Genellina" <gagsl-... at yahoo.com.ar> schreef in bericht
> >> >news:mailman.365.1209541507.12834.python-list at python.org...
>
> >> >> En Wed, 30 Apr 2008 04:19:22 -0300, SL <n... at hao.com> escribió:
> And
> >> >> that's a very reasonable place to search; I think chr and ord are
> >> >> builtin functions (and not str methods) just by an historical
> >> >> accident. (Or is there any other reason? what's wrong with
> >> >> "a".ord() or str.from_ordinal(65))?
>
> >> > yes when you know other OO languages you expect this. Anyone know
> >> > why builtins were chosen? Just curious
>
> >> *Maybe* for aesthetical reasons.  I find ord(c) more pleasent for
> >> the eye.  YMMV.
>
> >> The biggest ugliness though is ",".join().  No idea why this should
> >> be better than join(list, separator=" ").
>
> > Seconded. While we're at it, a third optional 'encode=str' argument
> > should be added, to the effect of:
>
> > def join(iterable, sep=' ', encode=str):
> >     return sep.join(encode(x) for x in iterable)
>
> > I can't count the times I've been bitten by TypeErrors raised on
> > ','.join(s) if s contains non-string objects; having to do
> > ','.join(map(str,s)) or ','.join(str(x) for x in s) gets old fast.
> > "Explicit is better than implicit" unless there is an obvious default.
>
> I'm afraid I don't agree with you on this. Most places where I use join
> I already know the type of the values being joined. In those few cases
> where I want to join non strings, or want to do some other processing on
> the values the generator comprehension is easy and has the advantage
> that I can use a more complex expression than a simple function call
> without having to wrap it in a lambda or otherwise contort things:
>
> e.g. comma.join(x[1] for x in s)
> vs.  comma.join(s, encode=operator.itemgetter(1))
> or   comma.join(s, encode=lambda x: x[1])

You don't have to use encode; you can write it as
join((x[1] for x in s), comma)

The main benefit of encode is its obvious default (=str), otherwise
it's not strictly necessary (although it is handy for named functions
e.g. encode=repr).

> Plus of course, you aren't going to be writing ','.join(str(x) for x in
> s) more than once in any given program before you extract it out to a
> function, are you?

In fact I am, not every one-liner needs to be a function. Just the
fact that such a function would live in a general utils module that I
have to import in most of my other modules (effectively making it a
two-liner) is not worth the few extra keystrokes.

George