The changes to the docs will definitely help in understanding why this
behaves as it does. I would like like to take one last stab though at
justifying why this behaviour isn't correct - will leave it alone if
these arguments don't stack up :)  Appreciate the input and
discussion.

Terry Jan Reedy wrote

> You are expecting that it run as a function namespace (with post 2.2
> nesting), when it is not a function. Why is that any better?

Because a class namespace (as I see it) was implemented to treat a
specific situation - i.e. that functions in classes cannot see class
variables. exec() is a far more generic instrument that has no such
explicit requirement - i.e. it feels like hijacking an edge case to
meet a requirement that doesn't exist. However 'all locals in an
enclosing scope are made available in the function namespace' is
generally understood as python's generic closure implementation, and
would match more effectively the generic nature of the exec()
statement.  A litmus test for this sort of thing - if you polled 100
knowledgeable python devs who hadn't encountered this problem or this
thread and asked if they would expect exec() to run as a class or
function namespace, I think you'd struggle to get 1 of them to expect
a class namespace. Functions are the more generic construct, and thus
more appropriate for the generic nature of exec() (IMHO).

It would appear that the only actual requirement not to make locals in
an enclosing scope available in a nested function scope is for a
class. The situation we are discussing seems have created a similar
requirement for exec(), but with no reason.

> In original Python, the snippet would have given an error whether you
> thought of it as being in a class or function context, which is how
> anyone who knew Python then would have expected. Consistency is not a bug.

> When nested function namespaces were introduced, the behavior of exec
> was left unchanged. Backward compatibility is not a bug.

Generally, most other behaviour did change - locals in enclosing
scopes *did* become available in the nested function namespace, which
was not backward compatible.  Why is a special case made to retain
consistency and backward compatibility for code run using exec()? It's
all python code. Inconsistent backward compatibility might be
considered a bug.

Cheers,

Colin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to