Re: computing with characters
- From: George Sakkis <george.sakkis@xxxxxxxxx>
- Date: Wed, 30 Apr 2008 09:56:43 -0700 (PDT)
On Apr 30, 5:06 am, Torsten Bronger <bron...@xxxxxxxxxxxxxxxxxxxxx>
wrote:
Hallöchen!
SL writes:
"Gabriel Genellina" <gagsl-...@xxxxxxxxxxxx> schreef in bericht
news:mailman.365.1209541507.12834.python-list@xxxxxxxxxxxxx
En Wed, 30 Apr 2008 04:19:22 -0300, SL <n...@xxxxxxx> 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
.
- Follow-Ups:
- Re: computing with characters
- From: Mel
- Re: computing with characters
- References:
- computing with characters
- From: SL
- Re: computing with characters
- From: Lutz Horn
- Re: computing with characters
- From: SL
- Re: computing with characters
- From: Gabriel Genellina
- Re: computing with characters
- From: SL
- Re: computing with characters
- From: Torsten Bronger
- computing with characters
- Prev by Date: Re: Sending Cntrl-C ??
- Next by Date: Re: PIL and IPTC
- Previous by thread: Re: computing with characters
- Next by thread: Re: computing with characters
- Index(es):
Relevant Pages
|
