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

[Vladimir Marangozov]

Hi,

Having read the PEP, most of the py-dev discussion and the EuroPython
slides just now (sorry, maybe I'm late by a couple of months :-), the
call for defense is a tough call for me.

I am -0.  There is no new functionality and actually my impression is
that there is potential for code readability to get hurt.

The argumentation for the change in the PEP seems to be weak.  It is
explicitly stated that successive @decos are equivalent to chained
function calls without the temp vars at definition time.  This is indeed
a key point.  No new functionality is actually added (or a good amount
of typed characters saved for that matter).

The staticmethod() readability problem is a code readability problem,
and as such it can simply be addressed the "classic" way via comments.
(BTW, has anyone suggested changing the @deco syntax to #deco? :-)
It works for me <0.5 wink>.

I do not necessarily perceive the foo = staticmethod(foo) transformation
statements as evil too.  They are explicit, normal def-time function
calls, and we certainly don't need a new way for the job.  We might
introduce one indeed (I saw the syntax becoming a fact of life already),
but we don't really need it to get the job done.  IOW, everything the
@decos can bring will remain doable the obvious way via function calls.
And that's good enough.

As for the arguments about future code tools knowing better about the
annotated functions / classes via the @decos at definition time, well,
it's common practice really (cf. #pragma and all sorts of special
comments for compile-time processing) which does not involve new syntax.
I perceive the extravaganza in doing one or the other as comparable.

That said, looking at what's being done here, and all things being
equal,
there is certainly some merit in the idea of declaring the def-time
caller list of a function before the function itself, but I personally
fail to foresee its goodness for Python on most counts.

These chained @decos look like a call stack crash dump to me anyway :-)

I will happily embrace genexps and multi-line imports though.  Thanks!

Cheers,
Vladimir