On Sat, Sep 26, 2020 at 10:43:01PM +0100, Nicholas Cole wrote:
I don't find such examples a conclusive argument in favour of this syntax at all.
I wouldn't expect you would -- Stefano made it up as an example of something that he felt was a poor use of subscripts! You should not be surprised that an example designed to be a poor fit for keyword subscripts is a poor fit for keyword subscripts.
I can't help feeling that this is a syntax looking for a set of solutions to apply itself to.
Have you read the PEP? This solves existing problems. The PEP gives examples of existing code that uses workarounds for the lack of this. # Existing df[df['x'] == 1] # Proposed df[x=1] # Existing ds["empty"].loc[{'lon': slice(1, 5), 'lat': slice(3, None)}] # Proposed ds["empty"][lon=1:5, lat=6:] Do you wish to say that the existing workarounds are superior to the proposed syntax? I know that for my own case, this would immediately solve a lot of problems for me. I'll be able to drop something like five proxy classes from a single public class: Public class: Matrix Proxies to support: * 1-based cell indexing (start at 1 rather than 0) * rows (0-based and 1-based) * columns (0-based and 1-based) Of course I could refuse to provide certain APIs, or redesign the Matrix class to use methods for indexing, but I'd much rather use indexing for indexing. This would be a far more natural and clean way of handling the interface, with a simpler implementation (no more proxies!).
It will add enormous complexity (together, no doubt, with speed issues and backwards-compatibility issues) to the language,
That is, I think, pure FUD. We have spent a lot of time working on this to ensure that there are no backwards compatibility issues, or at least none that are serious. By my recollection, the *only* change for existing code is that code like this: {}[None, kw=1] will change from a SyntaxError to a TypeError. As far as speed and complexity goes, I do not understand the C implementation well enough to categorically dismiss your claims, but from everything I have seen, neither is true: this should not have any significant slowdown, and the increase in complexity should be quite small. There have been more complex proposals that would require significantly more complex rules, and costly runtime look-ups. But this PEP rejects those. As far as I can tell, you are unfairly accusing the PEP of being everything that the PEP authors, and the Python-Ideas mailing list, has spent a *lot* of effort designing the PEP to *not* be. -- Steve