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

Overcoming herpetophobia (or what's up w/ Python scopes)?

P: n/a
kj

I'm a Perlhead (there, I said it). Years ago I made a genuine
attempt to learn Python, but my intense disappointed with the way
Python deals with scopes ultimately sapped my enthusiasm. I couldn't
live without closures and without the fine control over scopes that
Perl provides.

I've been wanting to make another attempt to (re)learn Python for
a while, but this scopes business remained a major damper. What's
pushing me over my reluctance is having to work with a large in-house
package developed in Python.

I am hoping that it may be better this time around. For one thing,
like Perl, Python was then (and maybe still is) a "work in progress."
So I figure that Python scoping may have improved since then. Even
if not, I think that Python is mature enough by now that adequate
alternatives must have been devised for the Perlish features that
I missed during my first attempt.

My question is: is there any tutorial on Python scoping aimed at
diehard Perlheads?

Thanks!

kj

--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
Jul 19 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
kj wrote:
I'm a Perlhead (there, I said it). Years ago I made a genuine
attempt to learn Python, but my intense disappointed with the way
Python deals with scopes ultimately sapped my enthusiasm. I couldn't
live without closures and without the fine control over scopes that
Perl provides.


Python has supported nested (lexical) scopes and closures since version 2.1, maybe this gives you enough control; see
http://www.amk.ca/python/2.1/index.h...00000000000000

Kent
Jul 19 '05 #2

P: n/a
This link seems to be about Closures in Python, but I am not feeling
sharp enough at the moment to evaluate the correctness of the
discussion.

http://en.wikipedia.org/wiki/Python_...guage#Closures

As others have said, you might get more useful responses if you can
elaborate upon what exactly you worry are shortcomings of Python
compared to Perl.

Jul 19 '05 #3

P: n/a
Python's current scoping differs from that in versions 2.1 and earlier
- statically nested (lexical) scoping was introduced under PEP 227.

I don't know what differences, if any, remain between Python's and
Perl's scoping rules, or if there is any tutorial concerning Python
scoping thats aimed specifically at programmers with a Perl background.
A pretty straightfoward explanation of the change to Python scoping
rules can be found at:

http://www.python.org/doc/2.2.3/whatsnew/node9.html

Jul 19 '05 #4

P: n/a
kj wrote:
I am hoping that it may be better this time around. For one thing,
like Perl, Python was then (and maybe still is) a "work in progress."
So I figure that Python scoping may have improved since then. Even
if not, I think that Python is mature enough by now that adequate
alternatives must have been devised for the Perlish features that
I missed during my first attempt.


I don't know of any tutorials, but given that you're familiar with the
concept of closures and scopes I don't think you really need one to
understand what Python does and doesn't provide.

Python does allow you to refer to variables in lexically enclosing
scopes, and it closes over them properly. Python (annoyingly) does
_not_ provide a way to write to the closed-over variable. Assignments
always go into the local scope. There is a "global" statement that
allows you to "target" the module scope; one can imagine an analagous
statement that allows you to target an intervening scope, but it
doesn't exist.

Some (incorrectly) interpret this to mean that the variable isn't
actually closed-over. The following code executes without errors,
which shows that the closure really does refer to the outer variable,
and not some constant copy:

def closure_test():
def make_closure():
def closure():
# a += 1 # this will give you an unbound local error at
runtime
return a
return closure
fn = make_closure()

a = 1
assert fn() == a
a = 2
assert fn() == a

closure_test()

The canonical way around this is to add a layer of indirection -- isn't
that always the solution?

def closure_test2():
def make_closure():
def closure():
a[0] += 1
return a[0]
return closure
fn = make_closure()

a = [1]
assert fn() == 2
assert fn() == 3
closure_test2()

p

Jul 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.