computing with characters

[George Sakkis]

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.

George