By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,923 Members | 1,279 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,923 IT Pros & Developers. It's quick & easy.

Avoiding local variable declarations?

P: n/a
I have some old Common Lisp functions I'd like to rewrite in Python
(I'm still new to Python), and one thing I miss is not having to
declare local variables.

For example, I have this Lisp function:

(defun random-char ()
"Generate a random char from one of [0-9][a-z][A-Z]"
(if (< 50 (random 100))
(code-char (+ (random 10) 48)) ; ascii 48 = 0
(code-char (+ (random 26) (if (< 50 (random 100)) 65 97))))) ;
ascii 65 = A, 97 = a

My Python version looks like this:

def random_char ():
'''Generate a random char from one of [0-9][a-z][A-Z]'''
if random.randrange(0, 100) 50:
return chr( random.randrange(0, 10) + 48 ) # ascii 48 = 0
else:
offset = 65 # ascii 65 = A
if random.randrange(0, 100) 50:
offset = 97 # ascii 97 = a
return chr( random.randrange(0, 26) + offset )

Logically, it's equivalent of the Lisp version.

But is there any way to avoid using the local variable (offset) in the
Python version?
Nov 13 '08 #1
Share this Question
Share on Google+
25 Replies


P: n/a
On Thu, Nov 13, 2008 at 2:22 PM, dpapathanasiou
<de*****************@gmail.comwrote:
I have some old Common Lisp functions I'd like to rewrite in Python
(I'm still new to Python), and one thing I miss is not having to
declare local variables.

For example, I have this Lisp function:

(defun random-char ()
"Generate a random char from one of [0-9][a-z][A-Z]"
(if (< 50 (random 100))
(code-char (+ (random 10) 48)) ; ascii 48 = 0
(code-char (+ (random 26) (if (< 50 (random 100)) 65 97))))) ;
ascii 65 = A, 97 = a

My Python version looks like this:

def random_char ():
'''Generate a random char from one of [0-9][a-z][A-Z]'''
if random.randrange(0, 100) 50:
return chr( random.randrange(0, 10) + 48 ) # ascii 48 = 0
else:
offset = 65 # ascii 65 = A
if random.randrange(0, 100) 50:
offset = 97 # ascii 97 = a
return chr( random.randrange(0, 26) + offset )

Logically, it's equivalent of the Lisp version.

But is there any way to avoid using the local variable (offset) in the
Python version?
Any time you port between languages, it's rarely a good idea to just
convert code verbatim. For example:

import random, string
def random_char():
return random.choice(string.ascii_letters + string.digits)
Nov 13 '08 #2

P: n/a
dpapathanasiou wrote:
I have some old Common Lisp functions I'd like to rewrite in Python
(I'm still new to Python), and one thing I miss is not having to
declare local variables.

For example, I have this Lisp function:

(defun random-char ()
"Generate a random char from one of [0-9][a-z][A-Z]"
(if (< 50 (random 100))
(code-char (+ (random 10) 48)) ; ascii 48 = 0
(code-char (+ (random 26) (if (< 50 (random 100)) 65 97))))) ;
ascii 65 = A, 97 = a

My Python version looks like this:

def random_char ():
'''Generate a random char from one of [0-9][a-z][A-Z]'''
if random.randrange(0, 100) 50:
return chr( random.randrange(0, 10) + 48 ) # ascii 48 = 0
else:
offset = 65 # ascii 65 = A
if random.randrange(0, 100) 50:
offset = 97 # ascii 97 = a
return chr( random.randrange(0, 26) + offset )

Logically, it's equivalent of the Lisp version.

But is there any way to avoid using the local variable (offset) in the
Python version?
Yes, you can avoid using offset, but *why*. This certainly won't make
your code cleaner or more easily read/understood/maintainable.

return chr( random.randrange(0, 26) + (97 if random.randrange(0,
100) 50 else 65)

or

if random.randrange(0, 100) 50:
return chr( random.randrange(0, 26) + 97)
else:
return chr( random.randrange(0, 26) + 65)

or

return chr( random.randrange(0, 26) + [26,97][random.randrange(0,
100) 50]

or

... probably other ways can be found ...

but what's wrong with you original code?
Gary Herron

--
http://mail.python.org/mailman/listinfo/python-list
Nov 13 '08 #3

P: n/a
return chr( random.randrange(0, 26) + (97 if random.randrange(0,
100) 50 else 65)
or

return chr( random.randrange(0, 26) + [26,97][random.randrange(0,
100) 50]
Ah, thanks, these are the syntax examples I was looking for.
but what's wrong with you original code?
I come from a functional programming school of thought, where you
avoid local variable declarations if at all possible.
Nov 13 '08 #4

P: n/a
Any time you port between languages, it's rarely a good idea to just
convert code verbatim. For example:

import random, string
def random_char():
return random.choice(string.ascii_letters + string.digits)
Good point, and thanks for the idiomatic Python example (I like the
conciseness); I'm still wrapping my mind around how Python statements
should be constructed.
Nov 13 '08 #5

P: n/a
"Gary Herron" <gh*****@islandtraining.comwrote in message
news:ma**************************************@pyth on.org...
return chr( random.randrange(0, 26) + [26,97][random.randrange(0,
100) 50]
return chr(random.randrange(0, 26) + (97 if random.randrange(0,100) 50
else 26))
Nov 13 '08 #6

P: n/a
In article <48**********************************@f40g2000pri. googlegroups.com>,
dpapathanasiou <de*****************@gmail.comwrote:
>
I come from a functional programming school of thought, where you
avoid local variable declarations if at all possible.
Python is *so* not a functional programming language. There are a number
of functional programming features available, but trying to push your
Python programs into primarily a functional style will result in
significantly poorer Python programs. Find another language if
functional programming is critical to your style.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
Nov 13 '08 #7

P: n/a
On Nov 13, 2:32*pm, "Chris Mellon" <arka...@gmail.comwrote:
On Thu, Nov 13, 2008 at 2:22 PM, dpapathanasiou

<denis.papathanas...@gmail.comwrote:
I have some old Common Lisp functions I'd like to rewrite in Python
(I'm still new to Python), and one thing I miss is not having to
declare local variables.
For example, I have this Lisp function:
(defun random-char ()
*"Generate a random char from one of [0-9][a-z][A-Z]"
*(if (< 50 (random 100))
* * *(code-char (+ (random 10) 48)) ; ascii 48 = 0
* * *(code-char (+ (random 26) (if (< 50 (random 100)) 65 97)))));
ascii 65 = A, 97 = a
My Python version looks like this:
def random_char ():
* *'''Generate a random char from one of [0-9][a-z][A-Z]'''
* *if random.randrange(0, 100) 50:
* * * *return chr( random.randrange(0, 10) + 48 ) # ascii 48 = 0
* *else:
* * * *offset = 65 # ascii 65 = A
* * * *if random.randrange(0, 100) 50:
* * * * * *offset = 97 # ascii 97 = a
* * * *return chr( random.randrange(0, 26) + offset )
Logically, it's equivalent of the Lisp version.
But is there any way to avoid using the local variable (offset) in the
Python version?

Any time you port between languages, it's rarely a good idea to just
convert code verbatim. For example:

import random, string
def random_char():
* * return random.choice(string.ascii_letters + string.digits)- Hide quoted text -

- Show quoted text -
Not quite. The original Lisp function first flips a coin to see if a
digit or alpha should be returned. If alpha, then flips a coin again
to see if upper or lower case should be returned. The alpha branch
could be collapsed into just returning a random selection from [A-Za-
z], but if you combine the alpha and numeric branches, you have less
than a 1/3 chance of getting a digit, vs. the 50-50 chance of the
original Lisp code.

Try this:

import random
import string
coinflip = lambda : int(random.random()*2)
if coinflip():
return random.choice(string.digits)
else:
return random.choice(string.ascii_letters)

or just:

return random.choice( (string.digits, string.ascii_letters)[coinflip
()] )

-- Paul
Nov 14 '08 #8

P: n/a
Paul McGuire:
coinflip = lambda : int(random.random()*2)
I warmly suggest you to use this instead:
randrange(2)

Bye,
bearophile
Nov 14 '08 #9

P: n/a
On Nov 13, 6:47*pm, bearophileH...@lycos.com wrote:
Paul McGuire:
coinflip = lambda : int(random.random()*2)

I warmly suggest you to use this instead:
randrange(2)

Bye,
bearophile
Really? Looking at randrange, it sure seems to do a lot of work in
pursuit of handling all possible cases for specifying range
boundaries, step values, etc. In fact, I think flipping a coin is a
common enough task that it might even merit an addition to the random
module API. It certainly would allow us to get rid of all of these
variations on the theme, such as "if randrange(100) 50", or
"random.choice([True,False])". For that matter, my own obscure int
(random.random() * 2) is better implemented using a direct comparison
to random.random(), no need for multiplication, or int calls or
anything else. Having an explicit method would also help prevent
minor erroneous bugs like "if random.random() 0.5", given that the
range of random.random() is (0.0, 1.0] (that is, the lower half would
be 0 inclusive to 0.5 exclusive, and the upper half 0.5 inclusive to
1.0 exclusive).

If I would change anything, I think I prefer the name coin_toss over
coinflip.

So:

coin_toss = lambda : random.random() >= 0.5

-- Paul
Nov 14 '08 #10

P: n/a
dpapathanasiou <de*****************@gmail.comwrites:
>but what's wrong with you original code?

I come from a functional programming school of thought, where you
avoid local variable declarations if at all possible.
Holding on to this principle won't help you write nice Python code :)

Although you will acquire lots of clever-looking tricks.

--
Arnaud
Nov 14 '08 #11

P: n/a
Paul McGuire:
Really? *Looking at randrange, it sure seems to do a lot of work in
pursuit of handling all possible cases for specifying range
boundaries, step values, etc.
Well, randrange is the simpler thing to read and understand here, and
maybe the one less likely to get wrong too.
But I understand your concerns. The solution is to write a C function
in the random module that implements the randrange in an efficient
way.

Bye,
bearophile
Nov 14 '08 #12

P: n/a
Chris Mellon <ar*****@gmail.comwrote:
Any time you port between languages, it's rarely a good idea to just
convert code verbatim. For example:

import random, string
def random_char():
return random.choice(string.ascii_letters + string.digits)
Note that this code doesn't preserve the output distribution of the
original, for which once expects half the characters to be numeric. I
don't know if that's relevant; in fact I suspect that the original was
buggy.

-- [mdw]
Nov 14 '08 #13

P: n/a
On Nov 14, 12:08*pm, Mark Wooding <m...@distorted.org.ukwrote:
Chris Mellon <arka...@gmail.comwrote:
Any time you port between languages, it's rarely a good idea to just
convert code verbatim. For example:
import random, string
def random_char():
* * return random.choice(string.ascii_letters + string.digits)

Note that this code doesn't preserve the output distribution of the
original, for which once expects half the characters to be numeric. *I
don't know if that's relevant; in fact I suspect that the original was
buggy.

-- [mdw]
I couldn't have said it better myself. Well, if not better, at least
earlier...
(http://groups.google.com/group/comp....779bf57e4d3a0?
hl=en)

-- Paul
Nov 14 '08 #14

P: n/a
On Thu, 13 Nov 2008 12:49:02 -0800 (PST), dpapathanasiou <de*****************@gmail.comwrote:
....
>but what's wrong with you original code?

I come from a functional programming school of thought, where you
avoid local variable declarations if at all possible.
I'm not sure that's universal. Using Standard ML at Uni, it was often
useful to use "let name = expr in expr" (or whatever the syntax was)
to simplify an expression. Directly borrowed from mathematics, I
assume.

'name' is not a variable, of course; there are no variables in
functional programming. Can't remember what it's called -- named
expression, maybe?

I think I use local names in Python about as much as I did in SML.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se R'lyeh wgah'nagl fhtagn!
Nov 17 '08 #15

P: n/a
On Mon, 17 Nov 2008 10:10:16 +0000, Jorgen Grahn wrote:
On Thu, 13 Nov 2008 12:49:02 -0800 (PST), dpapathanasiou
<de*****************@gmail.comwrote: ...
>>but what's wrong with you original code?

I come from a functional programming school of thought, where you avoid
local variable declarations if at all possible.

I'm not sure that's universal. Using Standard ML at Uni, it was often
useful to use "let name = expr in expr" (or whatever the syntax was) to
simplify an expression. Directly borrowed from mathematics, I assume.
That's (also?) Haskell syntax and I agree that it is useful to write
readable code.
'name' is not a variable, of course; there are no variables in
functional programming. Can't remember what it's called -- named
expression, maybe?
I think it's called variable and works like variables work in
mathematics, i.e. you can assign only once. Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here. :-)

Ciao,
Marc 'BlackJack' Rintsch
Nov 17 '08 #16

P: n/a
On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote:
Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here.
I don't quite know what you mean by "neutral element". I think you mean
the identity element under addition, which is zero, but that doesn't work:

0 = 0 + 1

Obviously not.

I think the only workable answer might be a = infinity, but that has two
problems: (1) infinity isn't a valid integer or real number (although
there is a valid float representing infinity on many platforms); and (2)
which infinity? Aleph 0, aleph 1, c, ... There's an infinite number of
them.

--
Steven
Nov 18 '08 #17

P: n/a
En Mon, 17 Nov 2008 22:18:51 -0200, Steven D'Aprano
<st****@remove.this.cybersource.com.auescribió:
On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote:
>Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here.

I don't quite know what you mean by "neutral element". I think you mean
the identity element under addition, which is zero, but that doesn't
work:

0 = 0 + 1

Obviously not.
Perhaps you didn't read carefully the above post? He said "unless *1* is
defined as the neutral element for ``+``"
Calling "1" the identity of the "+" operation, or calling "+" an operation
having "1" as its identity element is, errr, uncommon at least, but
perfectly valid...

--
Gabriel Genellina

Nov 18 '08 #18

P: n/a
On Nov 17, 5:12 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
En Mon, 17 Nov 2008 22:18:51 -0200, Steven D'Aprano
<ste...@remove.this.cybersource.com.auescribió:
On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote:
Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here.
I don't quite know what you mean by "neutral element". I think you mean
the identity element under addition, which is zero, but that doesn't
work:
0 = 0 + 1
Obviously not.

Perhaps you didn't read carefully the above post? He said "unless *1* is
defined as the neutral element for ``+``"
Calling "1" the identity of the "+" operation, or calling "+" an operation
having "1" as its identity element is, errr, uncommon at least, but
perfectly valid...

--
Gabriel Genellina
def __add__(self, other): return self + other - 1

Don't tell me this is not "Pythonic"!

Nov 18 '08 #19

P: n/a
On Mon, 17 Nov 2008 23:12:25 -0200, Gabriel Genellina wrote:

Perhaps you didn't read carefully the above post?
Er, yes, you got me on that.

:(
--
Steven
Nov 18 '08 #20

P: n/a
On Tue, 18 Nov 2008 00:18:51 +0000, Steven D'Aprano wrote:
On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote:
>Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here.

I don't quite know what you mean by "neutral element". I think you mean
the identity element […]
I knew I should have looked it up instead of "translating" it from my
mother tongue -- yes I ment "identity element". Sorry for the confusion.

Ciao,
Marc 'BlackJack' Rintch
Nov 18 '08 #21

P: n/a
Marc 'BlackJack' Rintsch <bj****@gmx.netwrites:
On Tue, 18 Nov 2008 00:18:51 +0000, Steven D'Aprano wrote:
>On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote:
>>Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here.

I don't quite know what you mean by "neutral element". I think you mean
the identity element […]

I knew I should have looked it up instead of "translating" it from my
mother tongue -- yes I ment "identity element". Sorry for the confusion.
Neutral element is correct. But maybe its use is limited to
mathematicians in the english-speaking word.

--
Arnaud
Nov 18 '08 #22

P: n/a
En Tue, 18 Nov 2008 16:27:46 -0200, Arnaud Delobelle
<ar*****@googlemail.comescribió:
Marc 'BlackJack' Rintsch <bj****@gmx.netwrites:
>On Tue, 18 Nov 2008 00:18:51 +0000, Steven D'Aprano wrote:
>>On Mon, 17 Nov 2008 12:32:35 +0000, Marc 'BlackJack' Rintsch wrote:

Not such illogical crap like
``a = a + 1`` which must be obviously false unless 1 is defined as the
neutral element for the definition of ``+`` here.

I don't quite know what you mean by "neutral element". I think you mean
the identity element […]
I knew I should have looked it up instead of "translating" it from my
mother tongue -- yes I ment "identity element". Sorry for the
confusion.
Neutral element is correct. But maybe its use is limited to
mathematicians in the english-speaking word.
In Spanish I've seen "elemento neutro" and "elemento identidad" used
interchangeably.

--
Gabriel Genellina

Nov 18 '08 #23

P: n/a
Arnaud Delobelle wrote:
Neutral element is correct. But maybe its use is limited to
mathematicians in the english-speaking word.
I've only ever seen "identity element" in English mathematics.
"Neutral element" sounds like something my car's gearbox
might have...

--
Greg
Nov 19 '08 #24

P: n/a
greg <gr**@cosc.canterbury.ac.nzwrote:
I've only ever seen "identity element" in English mathematics.
"Neutral element" sounds like something my car's gearbox
might have...
I've encountered both. I think `neutral element' is more common when
dealing with the possibility that it might not be unique (in the way
that identity elements are in groups, rings and fields), but that might
just be my misconception.

-- [mdw]
Nov 19 '08 #25

P: n/a
greg <gr**@cosc.canterbury.ac.nzwrites:
Arnaud Delobelle wrote:
>Neutral element is correct. But maybe its use is limited to
mathematicians in the english-speaking word.

I've only ever seen "identity element" in English mathematics.
"Neutral element" sounds like something my car's gearbox
might have...
I was an academic mathematician for several years (although not a very
good one) and I can assure you that 'neutral element' is correct and
understood. 'Unit element' is another common synonym.

Unfortunately I can't find a reference in one of the few books in
English that I have at home. Lang's "Algebra" does not seem to use the
term and it's the only undergraduate book I've got. Wikipedia and other
internet sources cite 'neutral element' as a synonym to 'identity
element'.

--
Arnaud
Nov 19 '08 #26

This discussion thread is closed

Replies have been disabled for this discussion.