[Python-Dev] Re: Call for defense of @decorators

["Martin v. Löwis"]

Christian Tismer wrote:
> I can think of a couple of ways to implement it. One would be
> to defer execution of a statement with undefined names until
> the end of the whole code block in the case of a class
> definition and to resolve the names late.

That would be counter-intuitive. If I have

    foo = func1(foo)
    def foo(self):
      body
    bar = foo

then your proposal is to execute foo=func1(foo) *after*
bar=foo. I doubt most users can understand that easily.

> Cleaner would probably be to have something like a placeholder
> for the undefined function, assign to the name a special
> object and trap the def statement to resolve the object.

That would require a new keyword, right? Which one?

> At the risk of getting slogged, I also thought of
> 
> myfunc := classmethod(myfunc)
> 
> for a short time, with ":=" as a late binding assignment
> operator which defers its operation until myfunc is
> defined, but I think this is not a popular idea. :-)

This is also a syntax change, and one that is going to
break existing tools: it reuses the colon, which many
tools expect to introduce a block of some sort.

> To save *some* typing (laziness was also a driver for this
> whole decorator nightmare), we could also remove the assignment
> and just have a function call like
> 
> classmethod(myfunc)

This breaks backward compatibility. This is already legal
syntax, and should raise a NameError if myfunc is not
defined (actually, this holds for the first proposal, too).
Furthermore, it might be that myfunc *is* defined, so
given

classmethod(myfunc)
def myfunc():
   body1

if some_condition():
   classmethod(myfunc)
   def myfunc():
     body2

you couldn't make the second definition of myfunc a classmethod.

> I could live
> with a special rule like my little proposal. 

Your proposals are all by no means little. They are significant,
counter-intuitive changes of the language.

> But must it be "@", such an eye-catching, ugly piece
> of flie-dirt?

If you don't like the current proposal, try to find objective
reasons, in addition to the subjective ones. Also, try to come
up with counter-proposals that are well thought-out, instead of
being created in a rush. In particular, if all you are concerned
with is the specific choice of operator, propose a different one.

Regards,
Martin