[Python-Dev] def ... decorate

[Josiah Carlson]

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

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


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

How does the discipline of a programmer have anything to do with the use
of signature-changing decorators?  When I (and I imagine most everyone
else) define a function or class, its signature tells me almost
everything I need to know about them.  What you are suggesting is that
this method of using signatures to describe functionality should not be
relied upon, because signatures can change.  That's like saying that I
shouldn't rely on the amount of money in my checking account, because
that amount changes.


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

You don't need to explain what it does.

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.

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

Also, if we were to give a language description of the lambda form you
describe, it would be:
Define an anonymous function with arguments args and body bdy,
decorating it with decorate, and naming it name.

Ick.

I much prefer: define a function called name, with arguments args,
decorated by decorator, with body bdy.  Which surprisingly enough looks
like...

def fun(args):
    @decorator
    #body

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.
def fun(args):
    body


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

Yes, lambda a mistake:
http://www.linuxjournal.com/article.php?sid=2959


> >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)?

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

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


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

No, I'm working on a PhD in computer science theory.  A few thousand
python-dev messages are just personal research into my favorite
programming language.

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

C4 is a derivative of what has been known since before March.
J3 has serious problems, as stated by Jack and myself.

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

Decorators are only part of the signature if you want them to be.  I
believe the vast majority of decorators will not change function
signatures.

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.


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


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

So then, it seems to me like the community should take a vote on what
symbol (if any) is better than @, and commit to sticking behind that one. 
If Guido likes it, great, we have a symbol; then we can argue about any
slight variation of Guido's preferred syntax (if he is willing to listen),
and call it good.

 - Josiah