On Tue, Oct 06, 2020 at 04:04:37PM +0100, Jonathan Fine wrote: > PEP 1, which defines the PEP process, states that any PEP that changes the > existing language specification should clearly explain "why the existing > language specification is inadequate to address the problem that the PEP > solves".
I believe that the PEP meets that requirement by showing the inelegant workarounds used by popular projects in the absence subscript keywords. PEP 1 doesn't require a PEP to show that the existing language is *incapable* of solving the problem. Python is Turing Complete, so it can solve any computable problem. There are Turing Complete languages with as few as two symbols: https://esolangs.org/wiki/Jot so in a sense everything is syntactic sugar. The PEP, in my opinion, satisfactorily demonstrates that the existing methods of getting the semantics of subscript keywords are awkward and ugly. > https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep > > As part of addressing this question of existing Python being adequate, I > wrote a new package kwey. This package provides, I believe, a class B such > that > >>> B(1, 2, a=3, b=4)[x] = val > is equivalent to > >>> x[1, 2, a=3, b=4] = val > once PEP 637 is implemented. (And if not, please report a bug, and if you > can provide a patch.) > https://pypi.org/project/kwkey/ Having to write something like `B(1, 2, a=3, b=4)[x]` would be an example of the awkwardness and inelegance that PEP 637 is designed to solve. If your kwkey package was a widely-known, commonly used third-party library, it would be a fantastic example of the sort of work-around that people fall back on in the absense of keyword subscripts. But I don't think that kwkey is widely used. It is a contrived library created in response to this issue being raised on the Python-Ideas mailing list, and as such, it would be a very weak example. A single widely-used example, such as from pandas or xarray, is worth a dozen contrived examples. So I'm not really sure what purpose you see your kwkey library taking in this PEP. As I mentioned in a previous post, I cannot tell whether you see it as competing with this PEP, complementary to the PEP, or perhaps as justifying the PEP? > GOAL > The current version of PEP 637 doesn't mention kwkey. I'd particularly like > us to look for problems where using kwkey as above is not adequate but PEP > 637 is adequate. > > Aside. Please treat this as a semantic problem, or in other words assume > that > >>> x[SOMETHING] > >>> f(SOMETHING) > impose the same constraint on a well-formed expression SOMETHING. But they don't. `f()` is legal; `f[]` is not, and will remain not legal. In addition, the precedences are different. In `f(a,b)` the use of the comma to separate arguments take precedence over the use of the comma to create tuples. But in `f[a,b]` it is the other way around. > Here's why. PEP 637 allows syntax such as > >>> x[1:2, 3:4, a=5:6, b=7:8] > and even after PEP 637 (as it currently is) > >>> f(1:2, 3:4, a=5:6, b=7:8) > is forbidden syntax. But PEP 637 is much more than a syntax extension. Adding slice literals is a separate, unrelated issue. Allowing slice syntax `start:stop:step` outside of subscripts is independent and orthogonal to this PEP. Please don't burden this PEP with it. > Recall that we already have literal expressions such as > >>> [1, 2, 3] # List literal > >>> (1, 2, 3) # Tuple literal > >>> {1, 2, 3} # Set literal Point of terminology: these are not literals (although informally people often call them that, including me on occassion). They are *displays*. One difference between a display and a literal can be seen from the byte-code generated: >>> import dis >>> dis.dis(compile('[1,2,3]', '', 'single')) 1 0 LOAD_CONST 0 (1) 2 LOAD_CONST 1 (2) 4 LOAD_CONST 2 (3) 6 BUILD_LIST 3 8 PRINT_EXPR 10 LOAD_CONST 3 (None) 12 RETURN_VALUE The constants 1, 2 and 3 are literals and the compiler can insert them directly into the code. The list [1, 2, 3] is not, the compiler has to insert code to create the list at runtime. > in Python. If current Python turns out to have adequate semantics, then > perhaps adding > >>> (1:2:3) # Slice literal > might by itself be enough. This is why I want particularly semantics > examples. They're worth more. Adding slice literals isn't enough. I believe that the PEP already discusses that we cannot write: f(spam=1) = 2 del f(spam=1) and this is a fundamental difference between a subscript and a function call. Of course Python is Turing Complete and we can always perform the same operation by creating proxies and wrappers and other levels of indirection. As they say, every problem can be solved by adding sufficient levels of indirection, except the problem of having too many levels of indirection. > CONCLUSION > I'd like to see semantic examples of problems that can be adequately solved > by PEP 637, but not by using kwkey. The PEP process says, in so many words, > that such examples should be provided. The most obvious problem that kwkey does not solve is the problem, how do I write a subscript with keywords without having to fall back on an inelegant and awkward work-around like kwkey? -- Steve _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2YWLV53H5ZOD2FT2B5R6GTKPPE2RCHOL/ Code of Conduct: http://python.org/psf/codeofconduct/
