elements of decorator syntax suggestions

[Dan Christensen]

I think this is identical to the following code, isn't it?

def f(a, b, c):
d = a * b
return d + c

Yes. The anonymity is used below.

[...]

Presto, you have decorators:
f = decorator1 @
decorator2 @
def (a,b,c):
d = a*b
return d + c
And the function name is at the top, like some people prefer.

I think if we asked them, they would clarify that it is not
the name *alone* which is important, but the *definition*.

Yes, I also feel that way. Having the function name first isn't the
real merit of my proposal. The merit (if there is any!) is that you
get a syntax much like the proposed @decorator syntax as a special
case of changes that feel more pythonesque (at least to me).

- anonymous functions are useful in their own right
- @ is just a new binary operator, which reduces punctuation
(parentheses)

It also allows a form such as

f = staticmethod @ def (a,b,c):
d = a * b
return d + c

which is fairly compact, although a little heavy on the
punctuation.

Sounds like another special case, as I'm not sure Python does
this for anything right now except when there are matched
opening and closing symbols.

That's true. Is there any reason that python doesn't automatically
continue all incomplete binary operators, allowing

x = a_very_long_expression +
another_long_expression

?

----

An alternate proposal for 2): if the parser finds

f x

where f is callable, interpret this as f(x). Then the examples
become

f = decorator1 \
decorator2 \
def (a,b,c):
d = a*b
return d + c

and

f = staticmethod def (a,b,c):
d = a * b
return d + c

But I guess this would introduce some ambiguity into the parser.
Right?

Dan

 

[Peter Hansen]

Is there any reason that python doesn't automatically
continue all incomplete binary operators, allowing

x = a_very_long_expression +
another_long_expression
?

Very likely, as is usual with Python, to avoid implicitly
assuming something that could well be wrong, thus failing
in a possibly very hard to find way, without warning.

x = a_very_long_expression +
some_function_that_might_return_a_value()

Now, was the first line a typo, with a missing extra value,
or was it really intended to add the result of the function
call on the second line?

x = a_very_long_expression + some_more
some_function_that_might_return_a_value()

If this is what the programmer intended, the implicit
approach could be disastrous.

-Peter

 

[Dan Christensen]

Very likely, as is usual with Python, to avoid implicitly
assuming something that could well be wrong, thus failing
in a possibly very hard to find way, without warning.

x = a_very_long_expression +
some_function_that_might_return_a_value()

Now, was the first line a typo, with a missing extra value,
or was it really intended to add the result of the function
call on the second line?

Good point. What if python did automatic continuation in this
situation only if the second line was further indented?

This is ok:

x = a_very_long_expression +
some_function_that_might_return_a_value()

This suggests the programmer forget to finish the first line:

x = a_very_long_expression +
some_function_that_might_return_a_value()

I just dislike those backslash characters. And I'm always
afraid there's hidden whitespace after them:
File "<stdin>", line 1
1 + \
^
SyntaxError: invalid token

Thanks for your comments!

Dan

 

[Peter Hansen]

Good point. What if python did automatic continuation in this
situation only if the second line was further indented?

I like. Don't know if it's been considered, but given
that it requires two distinct mistakes on the part of the
programmer, one after the other, it would be hard to argue
that it would happen often. The indentation part fits nicely
with Python in general.

By the way, you do know that instead of a backslash, lots
of us use parentheses around multi-line expressions? It
works fine, doesn't seem as ugly as \.

-Peter

 

[Jeffrey Froman]

I believe those of us who prefer to see the name first really
prefer to see something we might call the definition (and
"def" is well-named here) which includes a sign that we are
defining a function, very near the name, and preferably with
the argument list also very close (since it is generally quite
important to a reader)

For me, it's much more about the visual association of related statements.
Whitespace is critical for visual association in Python, and having
decorators floating above a definition absolutely wrecks the whole top-down
indentation scheme. I could learn to get used to the '@', because that
really *is* just a decorator, but having referential statements ride on top
of a function definition *breaks* the way python reads.

So I like Dan's idea as far as that goes, but in the same way I can also
live with

def f():
@decorator1
@decorator2

Jeffrey