[Python-Dev] def ... decorate
rnd at onego.ru
Sat Aug 14 07:53:51 CEST 2004
(I am resending it to c.l.p because I think it belongs there)
On Fri, 13 Aug 2004, Josiah Carlson wrote:
>You must be joking. Just because a signature can change doesn't mean
>that the signature is not important.
>I'll say it again, just in case you missed it the first time, the first
>major use of decorators are going to be in PyObjC, WHICH USES DECORATORS
>TO SPECIFY SIGNATURES.
>If you continue to claim that signatures are unimportant, I can't
>imagine how this discussion could continue in any sort of a productive
They are important. What I tried to say is that with decorators they sometime
change. It did not happen with plain def-statement. So resulting signature
must be in the docstring.
>Generally, describing decoration in terms of a functional approach
>is pointless, we already have a functional approach to decorations,
>which is what we are trying to remove.
...intead of making definitions squeezable into expression ;-)
as in this hypothetic example:
f = decorate(def args:
>f = decorate(f)
>Again, replace @ if desired.
>> I always thought the natural order of definition is value to define first,
>> definition to follow it.
>I don't know where this came from, but it is what we already have.
Probably, it comes from the math culture. Even HTML reflects this order.
Most programming languages also stick to it.
>> lambda a mistake? lambda a mistake... -OX
>Yes, lambda a mistake:
Maybe it was mistake to call it "lambda" a in math. But is Windows
directories are called folders. Terminology tends to downgrade for laymen.
>> >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.
>If you are so sure, why continue arguing towards your "J3" syntax (which
>is a variation on the syntax Skip proposed)?
My mind (and not only mine) is not static. Our discussion changed it.
The only way to proof a solution is good is by having two or more
>> 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...
>You are moving off-topic.
Just minor procedural note ;)
>> 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.
>Considering that you were, earlier today, offering a different syntax,
>this seems quite out of character for you.
See note above.
>I am not aware of decorators in other languages, but I have kept my nose
>out of most langauges developed since I discovered Python in 2000.
This is limiting your experience. In the same period I learned Ocaml alittle
where function signatures are part of type. Ocaml intrest me because it has
an efficient compiler (on par with C) but much less typing/functionality
>> Aren't decorators functional programming everyday feature, when
>> (in some programming languages) it is normal to define function as
>> a superposition of simpler ones?
>That is like saying that all programming is functional. Is prolog a
>functional programming language? No, it is a logic programming language,
>yet it is common in Prolog to see the following:
>my_and(a, b) = my_bool(a) and my_bool(b)
Not sure hat you wanted to express, but I wanted to say that in FP
languages decorators do not require special syntax as they are just
normal expressions involving function transformations.
Well, LISP doesn't require special syntax for any feature <wink>.
P.S. I feel tired by this discussion. And it is c.l.p one,
not python-dev. As we do not have enough ON TOPIC points
of disageement, I do not want to continue.
Sincerely yours, Roman Suzi
rnd at onego.ru =\= My AI powered by GNU/Linux RedHat 7.3
More information about the Python-list