[Python-ideas] Decorator syntax restriction

[Rob Cliffe]

Last time I wrote in favour of removing the restriction on decorator syntax, an unfortunate offhand remark of mine about something being more Pythonic led to a tangential debate about what was Pythonic and whether concision was always good, etc., with almost everyone ignoring the issue I was actually raising.
An honourable exception was Brett Cannon, who answered my points squarely (and did his best to shoot me down in flames).

So please, back to the point.
I argued in favour of removing the syntax restriction (i.e. allowing any expression after '@') on the following grounds, which I paraphrase from my original:

1(a)) It was inconsistent to impose a restriction on expressions in one particular context [meaning: and not in others].
1(b)) The restriction was hard to explain [but see below].
2) The restriction can easily be circumvented.
3) Plausible use cases exist [I gave some].

I would like to answer some of Brett's points here:

I wrote: "Guido has said he has a 'gut feeling' against [removing the restriction] but has not as far as I know rationalised it."
Brett wrote: "When it comes to Guido's gut, a rationalization isn't needed. Perk of being BDFL. Plus his gut is right so often it tends to not be questioned."

I am sure that Guido (may-he-live-forever) would be the first to agree that saying an opinion of his should NEVER be questioned is just, well, silly.

When I said in point 1(b)) above that the restriction was hard to explain, this was ambiguous.  Did I mean
 (i) It was hard to explain why there was a restriction at all.,
or
 (ii) It was hard to explain exactly what the restriction was.
?
Actually I intended (i), so my point 1(b) sort of overlaps with 1(a), but Brett in good faith anwered to (ii) and wrote "It's not difficult to explain; decorators can only be a dotted name w/
an optional method call and its corresponding arguments."

OK, but I at first got the wrong idea.  I was reading the book "Core Python programming" by Wesley J. Chun.  I quote from the book (page 422 section 11.3.6):
'The syntax for decorators uses a leading "at-sign" ( @ ) followed by the decorator function name and optional arguments.'
No mention, you see, of the fact that the function name could be a dotted name.  Nor AFAIK does a dotted name occur in any of the examples in the book.  In fact it didn't occur to me that it could be, until some of the correspondence included examples that used a dotted name.  So while it is possible to explain what the syntax restriction is, it is also possible to mis-explain it (or explain it poorly).  OK, this is probably more a criticism of the book than anything else, but it shows that an additional potential source of confusion has been introduced.

In reply to my IMO plausible use cases, Brett wrote:
"Plausible does not equal useful. You need to show that this actually comes up in normal coding for a decent amount of Python code to warrant tweaking the language over."

Why?  That would be correct if I were proposing adding a new language feature or changing the way an existing feature works and/or causing breakage of existing code.  But all I am proposing is lifting a restriction which at least arguably shouldn't have been there in the first place.  After all, in other contexts where an expression is expected, say on the RHS of an assignment statement, it is easy to write something nonsensical that nobody could produce a use case for, e.g.
    f() + f
    'a' - 'b'
    0/0
but nobody is suggesting that such constructs should be SYNTACTICALLY illegal, and quite right too.
Look at it this way: Suppose the restriction on decorator syntax had never been imposed.  Everyone who uses decorators would be using them in exactly the same way.  Would there be much of a case for then adding a restriction?  Would we be having this discussion at all?  I doubt it.

So: please speak, if you agree with me, whether for the reasons I give or for different ones, or if you disagree with me - please give reasons too.

Thanks and best wishes
Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20091002/ad9fb3ee/attachment.html>