computing with characters

George Sakkis george.sakkis at
Wed Apr 30 18:56:43 CEST 2008

On Apr 30, 5:06 am, Torsten Bronger <bron... at>
> Hallöchen!
> SL writes:
> > "Gabriel Genellina" <gagsl-... at> schreef in bericht
> >news:mailman.365.1209541507.12834.python-list at
> >> En Wed, 30 Apr 2008 04:19:22 -0300, SL <n... at> 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.


More information about the Python-list mailing list