«

For more information about Python's scoping rules, you can read parts of
the tutorial and language reference. Here are some relevant URLs:

Tutorial
9.2 Python Scopes and Name Spaces
http://www.python.org/doc/tut/node11...00000000000000

Language Reference
4.1 Naming and binding
http://www.python.org/doc/ref/naming.html

The rules are pretty simple, which probably means they're too simple to
do whatever you're trying to explain about Scheme.

You can write

def outer():
x = 3
def f(arg): return arg * x
return f(5)

to have outer() return 15, but you can't write

def outer():
x = 3
def f(arg): return arg * x
x = 4
return f(5)

to have outer() return 15, because 'f' will take the value of x from the
enclosing scope, and that value is 4 at the time of the call.

If you want to have f capture the value of x at that moment, you must
manually introduce another layer of nesting:

def outer():
x = 3
def inner(x):
def f(arg): return arg*x
return f
f = inner(x)
x = 4
return f(5)

or you can try to structure your code so that you can avoid re-using the
name 'x'. One common example of a situation where you can't avoid it
is something like this:

from Tkinter import *

def button_func(i):
print "pressed button", i

def make_stupid_gui():
t = Tk()
for i in range(10):
b = Button(t, text="Button #%d" % i,
command=lambda: button_func(i))
b.pack()
make_stupid_gui()

Instead, you must write

def make_stupid_gui():
t = Tk()
for i in range(10):
def make_binding(i):
return lambda: button_func(i)
b = Button(t, text="Button #%d" % i,
command=make_binding(i))
b.pack()

A programmer who is more comfortable with objects than with lambdas
might write something like this instead

class ButtonCallback:
def __init__(self, i): self.i = i
def __call__(self, i): print "pressed button", i

def make_stupid_gui():
t = Tk()
for i in range(10):
b = Button(t, text="Button #%d" % i,
command=ButtonCallback(i))
b.pack()
make_stupid_gui()

> PS: I'm a newbie, so the answer in fact might be super-easy.

Not an answer, but advice: when writing programs in Python, write Python
programs. If it's your task to translate some Scheme (or any other
language) into Python as literally as possible, my heart goes out to you.

Jeff

In article <mailman.1063592122.17998.python->,
Jeff Epler <> wrote:

<major snippage>

> Not an answer, but advice: when writing programs in Python, write Python
> programs.

Gawd, but that's profound! And on several levels... No... I'm serious.
But I'm also smiling.

> If it's your task to translate some Scheme (or any other
> language) into Python as literally as possible, my heart goes out to you.

How miserable do you expect me to be translating from Python to C/C++ as
literally as possible? Sounds like you think the Scheme guy has some
serious heartbreak ahead. So far, with a good working knowledge of C,
and picking up serious steam in C++ as I go, (Note 1) I'm trying to take
a Python program to C/C++, with a preference for C++. So far, here at
the very beginning of the start of the project, things *SEEM* to be
going well. I've got several simple routines from one of the classes
converted into pieces of a C++ class, and a few stub routines, and it
compiles & runs.

Note 1:
Been trying to teach myself C++ for a while now, and doing this port is
sorta my final exam in "Don learns C++ 101". Do I know enough to make it
happen? I do? Great! I don't? Drat! Go RTFM some more to see what I've
missed and correct the lack if I can figure out how. And if I can't
figure it out that way, well... There's always consulting with the
faculty and student body of Usenet University - Umpty-two-million
experts in 14-gazillion fields can't *ALL* be wrong simultaneously.

I hope...

On the way, I expect I'll pick up more than a little ability to read a
Python program, even if I never manage to type in a single line of
Python code. Not that learning to code in Python is a goal of this
project of mine, but hey... you can't avoid getting some of the source
language rubbed off on you when doing a port. Not if you want the port
to work, anyway.
Who knows... In the process of doing the port, I may begin to like
Python enough to actually try to use it.

--
Don Bruder - <--- Preferred Email - SpamAssassinated.
Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
I will choose a path that's clear: I will choose Free Will! - N. Peart
Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>

Don Bruder wrote:
> In article <mailman.1063592122.17998.python->,
> Jeff Epler <> wrote:
>
> <major snippage>
>
(and another one...)

> Who knows... In the process of doing the port, I may begin to like
> Python enough to actually try to use it.
>

Who knows ?-)

You may find out that what at first looked like a toy language finally
happens to be a real, full-blown and really powerful (from the
programmer's POV) application programming language...

Bruno

"Don Bruder" <> wrote in message
news0d9b.21665$...
> In article <mailman.1063592122.17998.python->,
> Jeff Epler <> wrote:
> > Not an answer, but advice: when writing programs in Python,
>> write Python programs.
>
> Gawd, but that's profound! And on several levels... No... I'm
serious.
> But I'm also smiling.

Jeff's advice is perhaps too terse for someone not already familiar
with it. Does the following seem more helpful?

If you are writing a Python program to either learn Python or
accomplish a computing task, you will probably be happier and more
successful (in the middle to long run) if you write idiomatic Python
rather than 'literal translations' in the style of some other langauge
and *its* idioms.

The OP is not the first to more or less ask 'how do I literally
translate this foreign idiom' (which the poster may not even see as a
language-specific idiom) rather than 'how do I accomplish the same
function'. This questions usually garner the advice given above.


> > If it's your task to translate some Scheme (or any other
> > language) into Python as literally as possible, my heart goes out
to you.

> How miserable do you expect me to be translating from
> Python to C/C++ as literally as possible?

In respect to the basic data/object model, Python is more similar to
Lisp than C++. In respect to syntax, the opposite is true.

By default, Python code is generic -- it runs with any object with the
needed interface. So, unless a block is explicitly specialized to one
type with a preceeding assert or conditional, the literally 'as
literal as possible' translation to C++ is to template code. Are you
doing this, or specializing the C++ code by declaring variables and
function parameters to a particular type?

Terry J. Reedy

In article <YJGdnbh7jKtyS_iiU->,
"Terry Reedy" <> wrote:

> "Don Bruder" <> wrote in message
> news0d9b.21665$...
> > In article <mailman.1063592122.17998.python->,
> > Jeff Epler <> wrote:
> > > Not an answer, but advice: when writing programs in Python,
> >> write Python programs.
> >
> > Gawd, but that's profound! And on several levels... No... I'm
> serious.
> > But I'm also smiling.
>
> Jeff's advice is perhaps too terse for someone not already familiar
> with it. Does the following seem more helpful?
>
> If you are writing a Python program to either learn Python or
> accomplish a computing task, you will probably be happier and more
> successful (in the middle to long run) if you write idiomatic Python
> rather than 'literal translations' in the style of some other langauge
> and *its* idioms.
>
> The OP is not the first to more or less ask 'how do I literally
> translate this foreign idiom' (which the poster may not even see as a
> language-specific idiom) rather than 'how do I accomplish the same
> function'. This questions usually garner the advice given above.

Like I said, that's *VERY* profound advice. It wasn't a question of me
"not understanding", it was an observation of fact. Even if it does make
me grin when I read it.

> > > If it's your task to translate some Scheme (or any other
> > > language) into Python as literally as possible, my heart goes out
> to you.
>
> > How miserable do you expect me to be translating from
> > Python to C/C++ as literally as possible?
>
> In respect to the basic data/object model, Python is more similar to
> Lisp than C++. In respect to syntax, the opposite is true.

I have (mercifully) forgotten almost all of the tiny bit of lisp I ever
knew. Never before or since have I seen such a butt-ugly, unfreindly,
difficult to deal with language. On second thought, I take that back...
Brainf*ck may be the only contender.

> By default, Python code is generic -- it runs with any object with the
> needed interface. So, unless a block is explicitly specialized to one
> type with a preceeding assert or conditional, the literally 'as
> literal as possible' translation to C++ is to template code. Are you
> doing this, or specializing the C++ code by declaring variables and
> function parameters to a particular type?

Definitely declaring variables. I'm nowhere near far enough along to
mess with templates yet. They just confuse me.

--
Don Bruder - <--- Preferred Email - SpamAssassinated.
Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
I will choose a path that's clear: I will choose Free Will! - N. Peart
Fly trap info pages: <http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>

Don Bruder wrote:
>
> In article <mailman.1063592122.17998.python->,
> Jeff Epler <> wrote:
>
> <major snippage>
>
> > Not an answer, but advice: when writing programs in Python, write Python
> > programs.
>
> Gawd, but that's profound! And on several levels... No... I'm serious.
> But I'm also smiling.

Only about as profound as the pithy sayings of "the Sphinx" in the
droll movie "Mystery Men"...

-Peter

Don Bruder <> wrote:
> Definitely declaring variables. I'm nowhere near far enough along to
> mess with templates yet. They just confuse me.

Templates seem to me (now - I still remember a time when they appeared
almost magical) a workaround for premature typing in C++. Reminds me
of Strachey's comments on IBM's Stretch computer: "Like some early
computer programs it is immensely ingenious, immensely complicated, and
extremely effective, but somehow at the same time crude, wasteful, and
inelegant, and one feels that there must be a better way of doing
things." Python, in comparison, seems to me to be an intelligent way of
employing the modern CPU.

--
automation: replacing what works with something that almost works,
but which is faster and cheaper. - attributed to Roger Needham