[Python-Dev] def ... decorate

[Roman Suzi]

On Fri, 13 Aug 2004, Josiah Carlson wrote:

>I've kept my nose out of the decorator discussion, but I thought I would
>give my opinion on this one...

>> Bingo!
>Oh god no.

;)

>> Just replace decorate with "from" and the nice syntax is found:
>>
>>     def f:
>>         staticmethod
>>         grammarrule('statement : expression')
>>         version("Added in 2.4")
>>         deprecatedmethod
>>         type_(None)
>>     from self, p:
>>         """docstring here"""
>>         print p[1]
>
>Gah, the horror.
>
>>  + doesn't surprise Python programmer, because it is like try-except, etc
>
>It surprises anyone who expects the function signature immediately after
>the name.

I do disagree. In my suggestion function is being defined in natural order
hich is illustratable by use of lambda:


f =                               \
  decor(                          \
    lambda arg:                   \
      return_val)

Decorators could be destructive and change function completely, so it's
pitiful signature doesn't mean much.

>>  + reads a natural language (with implicit "with"  after "f")
>
>But it is so radically different from current definitions that it breaks
>current understanding about the language.

Why? IMHO @s are much more radical.

>It also requires people to
>learn two significantly different semantics for defining a function.

No more "significantly different" than learning

import m

and

from m import something

>The good proposals (IMO) keep the function name and signature unchanged.
>
>So let us read this "natural language" (my interpretation of the syntax
>given above):
>
>define f as a staticmethod... from the arguments self and p with
>function body...  Not bad, though I don't like the visual aesthetics.

Ok. Now I see our disagrement. I am thinking in terms of
applying decorators to make some other function FROM
a given function while you are reasoning about "adding" attributes to the
defined function.

>>  + doesn't require any new keywords or symbols and "prefix" operators
>
>Prefix operators don't seem that bad to me, nor to Guido (who offered
>them in the first place), nor to the dozen+ others who have stated that
>"@, !, %, *, -, +, | or & is cool".

(ooops! I mean "prefix statements" - statements sticking to
other statements, modifying their semantics)

>As for keywords, there has been an offered solution; the use of a future
>import.  Similar to the way yield was used in 2.3.

IMO, decorators deserve no keywords...

>>From is an import semantic, not function definition.  Overloading 'from'
>does remove the necessity of a new keyword, but so does the use of the
>symbols previously offered.

I see no problem overloading preposition like "from", "as", "to", etc,
if it adds natural readability to language statements.

>>  + is explicit about transformation
>>  + no additional indentation
>
>Ahh, but you indent the block of decorators before the function
>definition must /always/ be read in order to figure out . While this has
>been done before (try, except, finally)

I mean "no additional" level, like other group decoration proposals.

>>  - grepping for defs now require more effort, so probably second name should
>>    be allowed after "from" or exactly this.

However, I am not sure Guido will change his mind and replace
'@' with something else. Probably, Python became too boring without
fresh syntax solutions like pies.

If so, I'd added a possibility to use ";" to delimit decorators:

@ decor1; decor2
def f(x):
  ...

Or:

@decor1; @decor2
def f(x):
  ...

May double pie mean "repeat last time used pie":

@staticmethod
def m(self, a):
  ...

@@
def n(self, a):
  ...


Sincerely yours, Roman Suzi
-- 
rnd at onego.ru =\= My AI powered by GNU/Linux RedHat 7.3