computing with characters
george.sakkis at gmail.com
Wed Apr 30 18:56:43 CEST 2008
On Apr 30, 5:06 am, Torsten Bronger <bron... at physik.rwth-aachen.de>
> 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.
More information about the Python-list