[Python-Dev] def ... decorate (original) (raw)

Roman Suzi rnd at onego.ru
Fri Aug 13 19:27:23 CEST 2004

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

More information about the Python-Dev mailing list