On 17 May 2014 11:40, Chris B accountearnstar@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-ch... has a few more examples of past changes that were accepted, and some of the key reasons why.
Cheers, Nick.