computing with characters

[Torsten Bronger]

Re: computing with characters

Hallöchen!

Marco Mariani writes:

Torsten Bronger wrote:
>

>However, join() is really bizarre. The list rather than the
>separator should be the leading actor.

>
No, because join must work with _any sequence_, and there is no
"sequence" type to put the join method on.

No, but for the sake of aesthetics (that's what we're talking here
after all), it would be better to have it as the first argument in a
build-in function.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bronger@jabber. org
(See http://ime.webhop.org for further contact info.)

[Duncan Booth]

Re: computing with characters

Torsten Bronger <bronger@physik .rwth-aachen.dewrote:

However, join() is really bizarre. The list rather than the
separator should be the leading actor.

Do you mean the list, or do you mean the list/the tuple/the dict/the
generator/the file and anything else which just happens to be an iterable
sequence of strings?

join is a factory method for creating a string from a separator string and
a sequence of strings, any sequence of strings. It doesn't make sense to
either limit it to specific sequence types, or to require it as part of the
iterator protocol.

Having it as a function would make sense, but if it is going to be a method
then it should be a method on the string types not on the sequence types.

[Diez B. Roggisch]

Re: computing with characters

However, join() is really bizarre. The list rather than the

separator should be the leading actor.

Certainly *not*! This would be the way ruby does it, and IMHO it does
not make sense to add join as a string-processing related
method/functionality to a general purpose sequence type. And as others
have pointed out, this would also mean that e.g.

def sgen():
for i in xrange(100):
yield str(i)

sgen.join(":")

wouldn't work or even further spread the join-functionality over even
more objects.

An argument for the original ord/chr debate btw is orthogonality: if you
want ord to be part of a string, you'd want chr to be part of ints -
which leads to ugly code due to parsing problems:

(100).chr()



Diez

[Torsten Bronger]

Re: computing with characters

Hallöchen!

Diez B. Roggisch writes:

>However, join() is really bizarre. The list rather than the
>separator should be the leading actor.

>
Certainly *not*! This would be the way ruby does it, and IMHO it
does not make sense to add join as a string-processing related
method/functionality to a general purpose sequence type.

Okay, my wording was unfortunate. However, I've already twice
(before and after the above posting of mine) said what I mean,
namely join(list, separator), possibly with a default value for
"separator" .

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bronger@jabber. org
(See http://ime.webhop.org for further contact info.)

[George Sakkis]

Re: computing with characters

On Apr 30, 5:06 am, Torsten Bronger <bron...@physik .rwth-aachen.de>
wrote:

Hallöchen!
>
SL writes:

"Gabriel Genellina" <gagsl-...@yahoo.com.a rschreef in bericht
news:mailman.36 5.1209541507.12 834.python-list@python.org ...

>

En Wed, 30 Apr 2008 04:19:22 -0300, SL <n...@hao.comes cribió: 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_ordina l(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(st r,s)) or ','.join(str(x) for x in s) gets old fast.
"Explicit is better than implicit" unless there is an obvious default.

George

[Carl Banks]

Re: computing with characters

On Apr 30, 6:47 am, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

Torsten Bronger <bron...@physik .rwth-aachen.dewrote:

The biggest ugliness though is ",".join(). No idea why this should
be better than join(list, separator=" "). Besides, ",".join(u" x")
yields an unicode object. This is confusing (but will probably go
away with Python 3).

>
It is only ugly because you aren't used to seeing method calls on string
literals.

I'm used to seeing it and I think it's ugly. Too terribly convenient
to not use, though (which is why I'm used to seeing it).


Carl Banks

[Mel]

Re: computing with characters

George Sakkis wrote:

def join(iterable, sep=' ', encode=str):
return sep.join(encode (x) for x in iterable)

Actually

return encode(sep).joi n(encode(x) for x in iterable)

lest you get TypeErrors for non-string separators.

Mel.

[Terry Reedy]

Re: computing with characters


"Marco Mariani" <marco@sferacar ta.comwrote in message
news:1TYRj.2730 6$o06.18162@tor nado.fastwebnet .it...
| Torsten Bronger wrote:
|
| However, join() is really bizarre. The list rather than the
| separator should be the leading actor.
|
| No, because join must work with _any sequence_, and there is no
| "sequence" type to put the join method on.

More generally, it works with any iterable, including dicts...

[George Sakkis]

Re: computing with characters

On Apr 30, 3:53 pm, Mel <mwil...@the-wire.comwrote:

George Sakkis wrote:

def join(iterable, sep=' ', encode=str):
return sep.join(encode (x) for x in iterable)

>
Actually
>
return encode(sep).joi n(encode(x) for x in iterable)
>
lest you get TypeErrors for non-string separators.

Well separator is almost always a string literal or at least known to
be a string, so that TypeError has never occured to me.

George

[Duncan Booth]

Re: computing with characters

George Sakkis <george.sakkis@ gmail.comwrote:

On Apr 30, 5:06 am, Torsten Bronger <bron...@physik .rwth-aachen.de>
wrote:

>Hallöchen!
>>
>SL writes:

"Gabriel Genellina" <gagsl-...@yahoo.com.a rschreef in bericht
>news:mailman.3 65.1209541507.1 2834.python-list@python.org ...

>>

>En Wed, 30 Apr 2008 04:19:22 -0300, SL <n...@hao.comes cribió:

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_ordina l(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(st r,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])

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?

[George Sakkis]

Re: computing with characters

On May 1, 3:36 am, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

George Sakkis <george.sak...@ gmail.comwrote:

On Apr 30, 5:06 am, Torsten Bronger <bron...@physik .rwth-aachen.de>
wrote:

Hallöchen!

>

SL writes:
"Gabriel Genellina" <gagsl-...@yahoo.com.a rschreef in bericht
news:mailman.36 5.1209541507.12 834.python-list@python.org ...

>

En Wed, 30 Apr 2008 04:19:22 -0300, SL <n...@hao.comes cribió:

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_ordina l(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(st r,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

[Boris Borcic]

Re: computing with characters

Duncan Booth wrote:

Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
>

>The biggest ugliness though is ",".join(). No idea why this should
>be better than join(list, separator=" "). Besides, ",".join(u" x")
>yields an unicode object. This is confusing (but will probably go
>away with Python 3).

>
It is only ugly because you aren't used to seeing method calls on string
literals.

An obviously independent cause of uglyness is the inconsistency of eg
','.split() and ','.join()

Cheers, BB

[cokofreedom@gmail.com]

Re: computing with characters

On May 6, 12:22 pm, Boris Borcic <bbor...@gmail. comwrote:

Duncan Booth wrote:

Torsten Bronger <bron...@physik .rwth-aachen.dewrote:

>

The biggest ugliness though is ",".join(). No idea why this should
be better than join(list, separator=" "). Besides, ",".join(u" x")
yields an unicode object. This is confusing (but will probably go
away with Python 3).

>

It is only ugly because you aren't used to seeing method calls on string
literals.

>
An obviously independent cause of uglyness is the inconsistency of eg
','.split() and ','.join()
>
Cheers, BB

I tend to do ", ".join("%s" % e for e in item)

Is there any difference between this and str()?

[Gabriel Genellina]

Re: computing with characters

En Tue, 06 May 2008 08:16:55 -0300, <cokofreedom@gm ail.comescribió :

I tend to do ", ".join("%s" % e for e in item)
>
Is there any difference between this and str()?

Use the timeit module to measure performance:

C:\TEMP>python -m timeit "for i in xrange(10000): str(i)"
10 loops, best of 3: 81.8 msec per loop

C:\TEMP>python -m timeit "for i in xrange(10000): '%s' % i"
10 loops, best of 3: 78.5 msec per loop

The %s version consistently wins in my system -2.5.1 on WinXP- for a wide range of inputs.

--
Gabriel Genellina