[Python-Dev] def ... decorate

[Josiah Carlson]

> 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.

Ahh, but you did:
"Decorators could be destructive and change function completely, so it's
pitiful signature doesn't mean much."

Even when a signature changes, the signature is important both before
and after.  The person who is changing the signature must know the
original, and the person who is using must know the changed.  In both
cases, the signature is important, although the second suffers from a
lack of obvious visual documentation.  This is why, "I believe that any
decorator that destroys a signature willingly should be considered
broken."


> >> 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.
> >def fun(args):
> >    body
> 
> Probably, it comes from the math culture. Even HTML reflects this order.
> Most programming languages also stick to it.

I meant in this discussion.  You brought it up in the scope of
decorating functions, but the vast majority of function definitions
are standard function definitions, which all follow the (name, value)
ordering.


> >> lambda a mistake? lambda a mistake... -OX
> >
> >Yes, lambda a mistake:
> >http://www.linuxjournal.com/article.php?sid=2959
> 
> Maybe it was mistake to call it "lambda" a in math. But is Windows
> directories are called folders. Terminology tends to downgrade for laymen.

If you read the article, it says that due to the scoping rules in Python
at the time, it wasn't a naming problem, it was that the functionality
shouldn't have been added.


> 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
> opposite opinions.

Ahh, you have given up on the J3 syntax.  Great.


> >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
> ratio.

As I already know the languages that are important for what I do (C/C++,
Lisp, Python, SML, Prolog, Mathematica), learning others is not a
priority.  Really, I should have stated myself more clearly in my
original post that you quote; I've browsed through various language
documentations over the last few years (Eiffel, Ocaml, Perl, Rexx, TCL,
etc.), but none of them made me jump out with "wow, that's awesome" as
Python did 4 years ago - which is why I haven't bothered to learn them.


> >> 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.

Even non-functional languages can /look/ like functional languages,
composing complex functions and algorithms from simple ones.  Python's
scoping and side-effects, I believe, keep it from being a functional
language.


> Well, LISP doesn't require special syntax for any feature <wink>.

If you want to be technical, Python doesn't require special syntax for
decoration, it just makes it more convenient.  And yes, I forgot about
Lisp.  Thinking about it, most languages with a sort of object
encapsulation ability allow decorations.  While it would be a bit ugly,
one could do function decoration with C++ and the lovely void*.

> 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.

Agreed.

 - Josiah