Are decorators really that different from metaclasses...

Paul Morrow pm_mon at yahoo.com
Thu Sep 2 07:03:50 EDT 2004


Jeff Epler wrote:
> I think it's crazy to change the language so that some of these
> functions give NameErrors when called, and others succeed.
> 
>      def f():         # Succeeds
>         if 1:
>             __x__ = None
>         return __x__
> 
>     def f2():        # Fails (but identical to above, today)
>         __x__ = None
>         return __x__
>

[snip]

With contrived examples, lots of things can look 'crazy'.  You don't 
really use __x__ as a local variable name do you?  That should be a 
compiler warning at least when you do that.  In fact, we obviously don't 
take magic variables seriously enough (IMO).  If we want to invent a new 
one, we should probably have to declare it somehow, otherwiwe you get a 
'undefined magic name' error.  That would make it a little harder to 
confuse the reader of your code.

So please try your examples again, but this time choose code that 
doesn't misuse magic variable syntax and which might possibly show up in 
the real world.


> You complicate the language when you create a new type of assignment
> that is special not because of the syntax, but because of the location
> in the suite of "def".
> 

docstrings are the precendent for this.


> You violate the law that most several special statements are expressible
> in terms of assignment (import, class, and def in terms of __import__,
> type(), and lambda:) or assignment plus looping (for in terms of while +
> except + assignment).
> 

Yep, only the equal sign ('=') would be allowed there.  That's not very 
limiting considering the intended purpose (making declarations), and it 
helps reinforce the visual separation of declaration and body.

> You also add a new constraint not expressible directly in the Grammar
> file.
> 

It would be easy to write a BNF expression that states that the optional 
docstring is followed by 0+ assignments to magic variables.  So what are 
you referring to here?


> What about these?  Are 2/3 of them now to be invalid syntax (and the
> remaining gives NameError)?  Or will they all compile, and 2/3 of them
> give an exception?
> 
>     def k():
>         __x__, y = range(2)
>         return __x__
> 
>     def k2():
>         y, __x__ = range(2)
>         return __x__
> 
>     def k3():
>         __y__, __x__ = range(2)
>         return __x__
> 

As above, I think that the answer to your question becomes obvious once 
you try to craft real-life examples, using properly named magic and 
local variables.

> Have you defined what happens in this case (I imagine that 'False' is
> the proper output, but I also believe that many would be surprised to
> get True)?
> 
>     __x__ = False
>     def m():
>         __x__ = True
>         __y__ = __x__ 
>     print m.__y__
> 
> Jeff
> 

Rewrite and you'll see...

      __author__ = 'Morrow'      # defines the container's author
      def m():
          __author__ = 'Smith'   # defines m's author
          __doc__ = __author__   # defines m's docstring
      print m.__doc__


Paul




More information about the Python-list mailing list