computing with characters

[SL]

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

'a' + 1 equals 'b' etc

 

[Gary Herron]

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.

Gary Herron

 

[Lutz Horn]

Hi,

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

So just for completion, the solution is:
'b'

Lutz

 

[Kam-Hung Soh]

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/Cookbook/Python/Recipe/65117

 

[SL]

Hi,



So just for completion, the solution is:

'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]

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_ordinal(65))?

 

[Arnaud Delobelle]

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

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

 

[SL]

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

yes it does, I just read the documentation on it

 

[SL]

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

 

[Gabriel Genellina]

En Wed, 30 Apr 2008 05:00:26 -0300, Arnaud Delobelle

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_ordinal(n)==chr(n), unicode.from_ordinal(n)==unichr(n)

 

[Marco Mariani]

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.

 

[Marc 'BlackJack' Rintsch]

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

 

[Diez B. Roggisch]

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

 

[George Sakkis]

Hallöchen!



*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

 

[Carl Banks]

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]

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

Actually

return encode(sep).join(encode(x) for x in iterable)

lest you get TypeErrors for non-string separators.

Mel.

 

[Terry Reedy]

| 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]

Actually

return encode(sep).join(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

 

[George Sakkis]

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

 

[Boris Borcic]

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