On May 1, 3:36 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > George Sakkis <[EMAIL PROTECTED]> wrote: > > On Apr 30, 5:06 am, Torsten Bronger <[EMAIL PROTECTED]> > > wrote: > >> Hallöchen! > > >> SL writes: > >> > "Gabriel Genellina" <[EMAIL PROTECTED]> schreef in bericht > >> >news:[EMAIL PROTECTED] > > >> >> En Wed, 30 Apr 2008 04:19:22 -0300, SL <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list