computing with characters

[SL]

How can I compute with the integer values of characters in python?
Like

'a' + 1 equals 'b' etc

[Gary Herron]

Re: computing with characters

SL wrote:

How can I compute with the integer values of characters in python?
Like
'a' + 1 equals 'b' etc
--
http://mail.python.org/mailman/listinfo/python-list

You can get an integer value from a character with the ord() function.

Gary Herron

[Lutz Horn]

Re: computing with characters

Hi,

2008/4/30 Gary Herron <gherron@island training.com>:

SL wrote:

How can I compute with the integer values of characters in python?
Like 'a' + 1 equals 'b' etc

>
You can get an integer value from a character with the ord() function.

So just for completion, the solution is:

>>chr(ord('a' ) + 1)

'b'

Lutz

--
Do you want a Google Mail invitation? Just write me an email!

[Kam-Hung Soh]

Re: computing with characters

On Wed, 30 Apr 2008 16:13:17 +1000, SL <ni@hao.comwrot e:

How can I compute with the integer values of characters in python?
Like 'a' + 1 equals 'b' etc

Try: ord('a')

See also: http://aspn.activestate.com/ASPN/Coo...n/Recipe/65117

--
Kam-Hung Soh <a href="http://kamhungsoh.com/blog">Software Salariman</a>

[SL]

Re: computing with characters


"Lutz Horn" <lutz.georg.hor n@googlemail.co mschreef in bericht
news:mailman.36 0.1209537877.12 834.python-list@python.org ...

Hi,
>
2008/4/30 Gary Herron <gherron@island training.com>:

>SL wrote:

How can I compute with the integer values of characters in python?
Like 'a' + 1 equals 'b' etc

>>
> You can get an integer value from a character with the ord() function.

>
So just for completion, the solution is:
>

>>>chr(ord('a ') + 1)

'b'

thanks :) I'm a beginner and I was expecting this to be a member of string
so I couldnt find it anywhere in the docs.

[Gabriel Genellina]

Re: computing with characters

En Wed, 30 Apr 2008 04:19:22 -0300, SL <ni@hao.comescr ibió:

"Lutz Horn" <lutz.georg.hor n@googlemail.co mschreef in bericht
news:mailman.36 0.1209537877.12 834.python-list@python.org ...

>>
>So just for completion, the solution is:
>>

>>>>chr(ord('a' ) + 1)

>'b'

>
thanks :) I'm a beginner and I was expecting this to be a member of
string so I couldnt find it anywhere in the docs.

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))?

--
Gabriel Genellina

[Arnaud Delobelle]

Re: computing with characters

"Gabriel Genellina" <gagsl-py2@yahoo.com.a rwrites:

En Wed, 30 Apr 2008 04:19:22 -0300, SL <ni@hao.comescr ibió:
>

>"Lutz Horn" <lutz.georg.hor n@googlemail.co mschreef in bericht
>news:mailman.3 60.1209537877.1 2834.python-list@python.org ...

>>>
>>So just for completion, the solution is:
>>>
>>>>>chr(ord('a ') + 1)
>>'b'

>>
>thanks :) I'm a beginner and I was expecting this to be a member of
>string so I couldnt find it anywhere in the docs.

>
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))?

Not a reason, but doesn't ord() word with unicode as well?

--
Arnaud

[SL]

Re: computing with characters


"Arnaud Delobelle" <arnodel@google mail.comschreef in bericht
news:m2d4o7bwmd .fsf@googlemail .com...

"Gabriel Genellina" <gagsl-py2@yahoo.com.a rwrites:
>

>En Wed, 30 Apr 2008 04:19:22 -0300, SL <ni@hao.comescr ibió:
>>

>>"Lutz Horn" <lutz.georg.hor n@googlemail.co mschreef in bericht
>>news:mailman. 360.1209537877. 12834.python-list@python.org ...
>>>>
>>>So just for completion, the solution is:
>>>>
>>>>>>chr(ord(' a') + 1)
>>>'b'
>>>
>>thanks :) I'm a beginner and I was expecting this to be a member of
>>string so I couldnt find it anywhere in the docs.

>>
>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))?

>
>
Not a reason, but doesn't ord() word with unicode as well?

yes it does, I just read the documentation on it :)

>
--
Arnaud
>

[SL]

Re: computing with characters


"Gabriel Genellina" <gagsl-py2@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 <ni@hao.comescr ibió:
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

>
--
Gabriel Genellina
>

[Torsten Bronger]

Re: computing with characters

Hallöchen!

SL writes:

"Gabriel Genellina" <gagsl-py2@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 <ni@hao.comescr ibió: 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=" "). Besides, ",".join(u" x")
yields an unicode object. This is confusing (but will probably go
away with Python 3).

Tschö,
Torsten.

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

[Gabriel Genellina]

Re: computing with characters

En Wed, 30 Apr 2008 05:00:26 -0300, Arnaud Delobelle
<arnodel@google mail.comescribi ó:

"Gabriel Genellina" <gagsl-py2@yahoo.com.a rwrites:
>

>En Wed, 30 Apr 2008 04:19:22 -0300, SL <ni@hao.comescr ibió:
>>

>>"Lutz Horn" <lutz.georg.hor n@googlemail.co mschreef in bericht
>>news:mailman. 360.1209537877. 12834.python-list@python.org ...
>>>>
>>>So just for completion, the solution is:
>>>>
>>>>>>chr(ord(' a') + 1)
>>>'b'
>>>
>>thanks :) I'm a beginner and I was expecting this to be a member of
>>string so I couldnt find it anywhere in the docs.

>>
>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))?

>
>
Not a reason, but doesn't ord() word with unicode as well?

Yes, so ord() could be an instance method of both str and unicode, like
upper(), strip(), and all of them...
And str.from_ordina l(n)==chr(n), unicode.from_or dinal(n)==unich r(n)

--
Gabriel Genellina

[Duncan Booth]

Re: computing with characters

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. Here are some arguably less-ugly alternatives:

print str.join(", ", sequence)

or:

comma_separated = ", ".join

will let you use:

print comma_separated (sequence)

or even just:

SEPARATOR = ", "

followed by:

SEPARATOR.join( sequence)

is no more ugly than any other method call.

It would make perfect sense for join to be a method on stringlike objects
if it simply returned an object of the same type as the object it is called
on. As you point out, where it breaks down is a str separator can return a
unicode result and that is confusing: if you want a unicode result perhaps
you should be required to use a unicode separator but that isn't going to
happen (at least not in Python 2.x).

What definitely wouldn't make sense would be to make join a method of the
list type (as it is in some other languages).

[Torsten Bronger]

Re: computing with characters

Hallöchen!

Duncan Booth writes:

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.

I am used to it. Programming very much with unicode, I use .encode
and .decode very often and I like them. I consider en/decoding to
be an intrinsic feature of strings, but not ord(), which is an
"external", rather administrative operation on strings (and actually
not even this, but on characters) for my taste.

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

Tschö,
Torsten.

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

[Marco Mariani]

Re: computing with characters

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.
This semantic certainly sets python apart from many other languages.

>>'-'.join(c for c in 'hello')

'h-e-l-l-o'

>>>

[Marc 'BlackJack' Rintsch]

Re: computing with characters

On Wed, 30 Apr 2008 13:12:05 +0200, Torsten Bronger wrote:

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

You mean any iterable should be the leading actor, bacause `str.join()`
works with any iterable. And that's why it is implemented *once* on
string and unicode objects. Okay that's twice. :-)

Ciao,
Marc 'BlackJack' Rintsch