[Python-Dev] def ... decorate

[Roman Suzi]

On Fri, 13 Aug 2004, Josiah Carlson wrote:

>> f =                               \
>>   decor(                          \
>>     lambda arg:                   \
>>       return_val)
>>
>> Decorators could be destructive and change function completely, so it's
>> pitiful signature doesn't mean much.
>
>That is funny, because in the 100,000+ lines of Python I've written over
>the years, function signatures are, in fact, important.

Of course, they are! However, with a possibility to apply decorators
function signature could change!

>Knowing a
>signature allows you to call a function, and I believe that any
>decorator that destroys a signature willingly should be considered
>broken.

Hmmmm... It's up to discipline of a programmer...

>As for the "natural order" of definitions, in Python, the natural order
>of definitions uses 'def', 'lambda' is considered by many (Guido
>included) to be a mistake.  I believe your argument using lambda is poor.

def f (args): body
f = lambda args: body

Hmmm... slightly diferent order, indeed. But quite understandable,
because lambda creates anonymous function in an expression, while
def does namebinding.

I always thought the natural order of definition is value to define first,
definition to follow it.

lambda a mistake? lambda a mistake... -OX

>> >>  + 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.
>
>Seemingly in Guido's opinion, @s (or other symbols) were minimal.  You
>can have a humble (or not so humble) opinion, but unless you can
>convince Guido and/or the community, it is not going to happen (I've
>been bitten by this myself).

I am pretty sure @-syntax will do it into Python 2.4 and I am also
sure that nobody will remeber these discussions 1-2 years from now.

I wonder WHAT Python looked like if it's community discussed
EVERY syntax feature it had before 1.5.2. My feeling is Python
still missed IF-THEN-ELSE...

GvR already decided on the syntax. His brain has already
calculated all those millions of possibilities (moves),
community response included. We have almost zero chance to
find better syntax for decorators.

>> >It also requires people to
>> >learn two significantly different semantics for defining a function.
>>
>> >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.
>
>No, our disagreement isn't about how we understand decorators.  I never
>argue it is about adding attributes, as I have actually read the 1800+

I hope you do not receive treatment at mental hospital right now? ;-)
(Disclaimer: no pun intended. Just expressing my surprise)

>postings on decorators in the last 8 months, where attributes are
>basically stated as being not arguable.

>Our disagreement is about what is a reasonable decorator syntax.  I
>don't believe that anything that changes the look of a function
>signature to be a reasonable decorator syntax.

In fact, I've already proposed 2 syntaxes: C4 and J3.

But aren't decorators part of a signature? Are there any languages with
decorators similar to being implemented in Python?
(Full-fledged, not things like "static volatile ..." in C/Java/C++ like
languages.)

Aren't decorators functional programming everyday feature, when
(in some programming languages) it is normal to define function as
a superposition of simpler ones?

[ neither "as" nor "to" are keywords ] ok

>> I mean "no additional" level, like other group decoration proposals.
>
>Oops, I didn't finish my argument.
>
>I know what you meant.  In order to understand what a function does, one
>must read the decorators.  While associated indented blocks have been
>done before (try, except, finally, else), one doesn't need to read the
>try block to understand that if an exception were to occur, the except
>block would be executed.  In order to understand the semantics of a
>function definition, you need to read the decorators.  Having an
>indented block previous to the function definition, which includes the
>decorators for the function below, only makes sense if the name is given
>before the decorators (the brain-stack argument).

> However, since the
>function signature is as important as any decorator, then the signature
>should be prominant.


>I believe your arguments are better focused toward a different syntax,
>namely:
>
>def fun(args):
>    @deco
>    #body
>
>I think it beats your offered syntax hands-down due to its conciseness
>and lack of need to include a separate indented block for decorations.
>It also doesn't require re-learning the meaning of "from".

>> 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.
>
>Guido has stated, quite clearly, that if we can come up with a better
>symbol than "@", then he will go with it.

The ord "better" is subjective. In this case it means "better"
in Guido's view. Probably, we can even write a syntax-proposing
program which could give thousands of variants (and probably even
validate them with existing Python grammar to exclude clashes)
from which Guido could choose. Wiki already has enough material to
do this sort of machine.



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