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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4