Update to PEP 227 (static scoping)

[Aahz Maruch]

[p&e]

[I don't really have any comments on this proposal, but to prove that
I've read it ;-), I'm including a list proofreading fixes.]

In article <mailman.982783412.29104.python-list at python.org>,
Jeremy Hylton  <jeremy at alum.mit.edu> wrote:
>
>Introduction
>
>    This proposal changes the rules for resolving free variables in
>    Python functions.  The Python 2.0 definition specifies exactly
>    three namespaces to check for each name -- the local namespace,
>    the global namespace, and the builtin namespace.  According to
>    this defintion, if a function A is defined within a function B,
>    the names bound in B are not visible in A.  The proposal changes
>    the rules so that names bound in B are visible in A (unless A
>    contains a name binding that hides the binding in B).

s/defintion/definition/

>Specification
>
>    Python is a statically scoped language with block structure, in
>    the traditional of Algol.  A code block or region, such as a
>    module, class defintion, or function body, is the basic unit of a
>    program.

s/defintion/definition/

>    If the global statement occurs within a block, all uses of the
>    name specified in the statement refer to the binding of that name
>    in the top-level namespace.  Names are resolved in the top-level
>    namespace by searching the global namespace, the namespace of the
>    module containing the code block, and the builtin namespace, the
>    namespace of the module __builtin__.  The global namespace is
>    searched first.  If the name is not found there, the builtin
>    namespace is searched.

Clarification: if the global statement is not the first executable
statement in a block, the results are undefined.

>    If exec is used in a function and the function contains a nested
>    block with free variables, the compiler will raise a SyntaxError
>    unless the exec explicit specifies the local namespace for the
>    exec.  (In other words, "exec obj" would be illegal, but 
>    "exec obj in ns" would be legal.)

s/explicit/explicitly/

>    Names in class scope are not accessible.  Names are resolved in
>    the innermost enclosing function scope.  If a class defintion
>    occurs in a chain of nested scopes, the resolution process skips
>    class definitions.  This rule prevents odd interactions between
>    class attributes and local variable access.  If a name binding
>    operation occurs in a class defintion, it creates an attribute on
>    the resulting class object.  To access this variable in a method,
>    or in a function nested within a method, an attribute reference
>    must be used, either via self or via the class name.

s/defintion/definition/

>    The global statement short-circuits the normal rules.  Under the
>    proposal, the global statement has exactly the same effect that it
>    does for Python 2.0.  It's behavior is preserved for backwards
>    compatibility.  It is also noteworthy because it allows name
>    binding operations performed in one block to change bindings in
>    another block (the module).

s/It's/Its/

>    An example from Tim Peters of the potential pitfalls of nested scopes
>    in the absence of declarations:

Clarification: s/Peters of/Peters demonstrates/

>Backwards compatibility
>
>    There are two kinds of compatibility problems caused by nested
>    scopes.  In one case, code that behaved one way in earlier
>    versions, behaves differently because of nested scopes.  In the
>    other cases, certain constructs interact badly with nested scopes
>    and will trigger SyntaxErrors at compile time.

s/versions,/versions/

>    At compile-time, the compiler cannot tell whether an exec that
>    operators on the local namespace or an import * will introduce
>    name bindings that shadow the global y.  Thus, it is not possible
>    to tell whether the reference to y in g() should refer to the
>    global or to a local name in f().

s/operators/operates/

>    The implementation adds several new opcodes and two new kinds of
>    names in code objects.  A variable can be either a cell variable
>    or a free variable for a particular code object.  A cell variable
>    is referenced by containing scopes; as a result, the function
>    where it is defined must allocate separate storage for it on each
>    invocation.  A free variable is reference via a function's closure.

s/reference/referenced/
-- 
                      --- Aahz (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

The problem with an ever-changing .sig is that you have to keep changing it