RetroSearch Browse

Sun Mar 28 08:40:48 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/043604.html

    Paul> Guido's proposal explicitly defined two unrelated syntaxes for two
    Paul> unrelated features dealing with these two unrelated use
    Paul> cases. Rather than arguing with him, you should be supporting
    Paul> him. The people you should be arguing with are people who want to
    Paul> use one syntax for both, because this will lead to a design which
    Paul> is suboptimal for what you call "true decorators".

Given that what can go inside the square brackets will be pretty general (no
matter what you think should go there), annotations can be applied to
functions and classes with the proposed syntax.  If a general-purpose
decorator syntax is added to the language before something like Guido's '@'
expressions (which I find not at all Pythonic), my guess is that will make
it easy enough for people to annotate functions and that will become the
preferred mechanism.  Let go long enough, it will supplant the need for '@'
expressions altogether.

My argument against '@' expressions is simply that they will be confusing.
They will appear to be part of the function body, and unlike doc strings
will almost certainly involve evaluation of general expressions, at least in
some cases.  I think that will make it confusing (for newbies, at least)
that those expressions are actually evaluated at function definition time
and not at function execution time.

    >> Let's keep the discussion on PEP 318 focused on decorators. I'm happy
    >> to have it stated (in the PEP, if you like) that a decorator like
    >> attributes is an abuse and is strongly discouraged. But I don't think
    >> that the existence of an abuse is justification for rejection of the
    >> feature.

    Paul> Who is talking about rejecting any feature?

I would be happy to see the '@' expression proposal disappear. ;-)

    Paul> Anyhow, I do not believe that the two features are as unrelated as
    Paul> you think.

    Paul> First: we do not want to introduce a new feature that will
    Paul> ENCOURAGE abuse. Better to introduce two features and head that
    Paul> off at the pass.

That requires another PEP.  PEP 318 isn't about a syntax for function
attributes.  It's about more general function, method and class decorators

    Paul> Second: I see use cases like this:

    Paul> def foo [spark_callback] (self):
    Paul>       @spark_rule = "DOC := HEAD BODY FOOT"
    Paul>       ...

    Paul> def foo [publish_to_web](self):
    Paul>       @url = "/cgi-bin/directory/directory"

    Paul> Otherwise you get into a lot of this stuff:

    Paul> def foo[publish_to_web("http://directory/directory")](self):
    Paul>       ...

Your example only scratches the surface and doesn't obviously show
decorators used to set function attributes.  Besides, if you mean that
publish_to_web be called with the value of foo.url set, it's not clear to me
that foo.url will be available when publish_to_web(foo) is called.  You use
simple '@' notation examples with string literal values and a decorator
example which is not directly related to those examples.  I think

    def foo(self) [attrs(spark_rule="DOC := HEAD BODY FOOT",
                         url="/cgi-bin/directory/directory"),
                   publish_to_web]:

looks perfectly reasonable.  It places the attribute definitions near the
top of the function definition without it becoming visually part of the
function body, and there's less uncertainty about when attrs() is called in
relation to publish_to_web().

Skip

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-March/043604.html below:

[Python-Dev] Re: method decorators (PEP 318)