[Python-ideas] Extending the usage of the @ decoration operator.

[Nick Coghlan]

On 17 May 2014 11:40, Chris B <accountearnstar at gmail.com> wrote:
> I'm not sure where to go from here. Does this idea qualify for a PEP? Is it
> even possible to be implemented? Has it already been discussed? What do you
> think about it? Please share your opinions, suggestions and improvements!

Others have noted that this specific proposal conflicts with the
already accepted matrix multiplication operator, but there are some
more general questions to ask yourself when making syntax proposals:

* what problem am I trying to solve?
* how common is that problem in general?
* what are the existing solutions to that problem?
* how easy is it to make a mistake when relying on the existing solutions?
* how does the readability of the new syntax compare to existing code?
* how much harder will it be to learn Python after this proposal is added?

For example, the original decorator syntax solved a significant
readability problem:

    def method(a, b, c): # Where is self????
        # many
        # lines
        # of
        # implementation

    method = staticmethod(method) # Oh, it's a static method

vs

    @staticmethod
    def method(a, b, c): # Obviously no self needed
        # many
        # lines
        # of
        # implementation

By contrast, a new way of spelling the "method = staticmethod(method)"
line isn't particularly interesting - it doesn't add much
expressiveness to the language, just a new way of spelling something
that can already be written out explicitly. Adding a complicated way
of avoiding writing multiple assignment statements or a helper
function also isn't compelling:

    p1, p2 @ expandvars, abspath, normcase, curry(relpath, start)

vs

    def fixpath(p):
        return expandvars(abspath(normcase(relpath(start, p))))

    p1 = fixpath(input('Insert path here: '))
    p2 = fixpath(input('And another path here: '))

Python aspires to be "executable pseudocode". While we often fall
short of that mark, it does at least mean we're willing to sacrifice a
little brevity for the sake of clarity.

For a more recent example of a successful syntax change proposal, the
numeric Python community were able to make their case for a new matrix
multiplication operator because they have been trying to solve it
*without* a new operator for more than a decade, but haven't been able
to come up with a non-syntactic solution that they were all happy
with. The PEP was accepted in short order because they were able to
demonstrate two things:

1. Yes, they really needed new syntax to solve the problem properly
2. No, they weren't likely to be back in a couple of years time asking
for *another* operator in 3.6 - matrix multiplication really was the
only thing they had found they didn't have a good clean spelling for

http://www.curiousefficiency.org/posts/2011/02/justifying-python-language-changes.html
has a few more examples of past changes that were accepted, and some
of the key reasons why.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia