[Python-Dev] PEP 318 - generality of list; restrictions on elements

[Phillip J. Eby]

At 02:21 PM 3/8/04 -0500, Jewett, Jim J wrote:
>Given that some syntax will be chosen, what are the
>restrictions on the wrappers?
>
>Right now, the variable portion of the syntax is:
>
>         '[' wrapper (, wrapper)* ']'
>
>What else should be accepted, to avoid surprises?
>
>         Variables that evaluate to a list?
>         Expressions that evaluate to a list?
>         List comprehensions?
>         Single wrappers?

None of the above.  It's a list constant, period.


>What are the restrictions on list items?
>
>         Only a function?
>         Only a code object?  (I assume so)
>         Must the code return the original function?
>         Must the code return a code object?

Any callable object.  May return anything.



>In other words, which of the following examples
>should work, which should fail, and which should
>depend on whatever is easiest?
>
>1.      # fail, integer not a callable?  (Don't try to slice the args!)
>         def name(args)[0]:
>
>2.      # fail, as w[0] is itself a (non-callable) list?
>         w = [wrapper]
>         def name(args) [w]:
>
>3.      # fail, not a list?
>         def name(args) classmethod:

This one's a syntax error.


>4.      # ??? lambda would be OK, except for the second ":"
>         def name(args)[lambda x: x]:

This should work.

>5.      # should succeed?
>         def name(args)[x for x in decorators if x in active]:

Should fail.


>6.      # ??? wrapper does not return a callable.
>         y = lambda x: None
>         def name(args) [y]:

Should succeed.


>7.      # a list, but no '[]'.  either surprises.
>         def name(args) list((wrap1, wrap2)):

Syntax error.


>8.      # a list, but no '[]'.  either surprises.
>         w = [wrapper]
>         def name(args) w:

Syntax error.


>9.      # a list, but no '[]'.  either surprises.
>         def w(): return [y,y,y]
>         def name(args) w():

Syntax error.



>Do the wrappers have to be defined when the definition starts?
>Just defined before the module finishes its definition?
>Before the definition is executed?  In other words, are these OK?

The expressions are evaluated after the function or class object is 
created, but *before* it is bound to the name defined in the def or class 
statement.


>def outer():
>     # w not defined at module load, but defined before any call
>     def inner(x)[w]:
>         print x
>     return inner

This is fine.


>But if that is OK, then which w would be used in the next example?
>w is redefined "later", but before inner is actually called.
>
>def w(fn):
>     print "outside w"
>     return fn
>
>def outer():
>     # w not defined yet, but defined in this
>     def inner(x)[w]:
>         print x
>     def w(fn):
>         return fn
>     inner(5)

You're going to get an UnboundLocalError for this code, because 'w' is 
defined in 'outer', and therefore obscures the global 'w'.

Also, remember that wrapping takes place when the function object is about 
to be assigned to the name 'inner', so the execution of 'inner' has nothing 
to do with anything.


>How about this?  There is no guarantee that othermod
>will finish loading first, though I suppose that
>already causes problems today.
>
>import othermod
>def fn()[othermod.wrap]:
>     pass

What are you talking about?  The only way that's not guaranteed is if 
othermod is importing the current module, and if wrap isn't yet defined, 
then an AttributeError will occur here.