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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/M3LTGWS3JN6QHLPF7CKBPRU7ZY56QQFF/
Code of Conduct: http://python.org/psf/codeofconduct/
