[Python-Dev] Re: Call for defense of @decorators (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sat Aug 7 06:19:08 CEST 2004

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

More information about the Python-Dev mailing list