Are decorators really that different from metaclasses...

Arthur ajsiegel at
Thu Aug 26 14:34:16 CEST 2004

On Thu, 26 Aug 2004 17:31:16 +1000, Anthony Baxter
<anthonybaxter at> wrote:

>On Wed, 25 Aug 2004 19:47:35 -0400, Paul Morrow <pm_mon at> wrote:
>> What you're trying to illustrate (I believe) is a superclass doing
>> something based on the docstring of a subclass.  Yes this certainly does
>> happen.  But the superclass and subclass are separate objects.  I was
>> talking about the situation where a function does something based on
>> /its own/ metadata.  That is what I'm saying virtually never happens,
>> and therefore it's ok to make all assignments to __xxx__ attributes
>> inside of a function def create /function attributes/ rather than /local
>> variables/.
>This is an extraordinarily complex idea - you're proposing that inside
>a function there is now access to a brand new namespace, that of the
>function object itself. I don't think you appreciate just _how_ much
>work this would requre, nor the complexity of trying to explain this
>to users. Remember, at the moment, you can't even get access to the
>function object itself from inside the function, without using a hack
>like sys._getframe() or raising an exception.
>Putting aside nested scopes for the moment, there are three namespaces
>that are used in Python - local, module level global, and builtins.
>You're proposing that there is a new namespace, that of the function
>object, and that it only be used by accessing any local variable that
>starts or ends with two underscores. At the moment, the scoping rules
>for Python are _extremely_ simple. Do you really want to add something
>like this, that looks like a hack, smells like a hack, and who's
>implementation would be a hack? I know I don't want to see something
>like this.

Though I am learning stuff by trying to keep up with this conversation
- I should probably stay out of it, directly.

But, as I publically demonstrated in my confusion about __name__ someone educated from within Python, mostly by chucking out
code, rather than reading documentation - that  __name__  accessed
from within the function body is something totally different from
__name__ accessed from outside of it, was not what I think the
language taught me to expect.  I might have intuited that to expect
otherwise would be "magic", but thought, somehow, that the __xxx__
implied the availability of that kind of magic. 

In other words, it would have surprised me less to have been right
than to have benn wrong.

Though I have learned not to be shocked about being wrong ;)

And can understand the possiblity that others with other backgrounds
might be surprised if I had been right.


Namespaces are one honking great idea -- let's do more of those!

come into play here at all?


More information about the Python-list mailing list