On Sat, Aug 29, 2020, 5:08 AM Paul Moore <p.f.mo...@gmail.com> wrote:
> There seems to be quite a lot of tendency here (not just you, others
> are doing it too) to assume "you didn't find my arguments convincing,
> so I'll explain them again and hopefully you'll understand them
> better". The problem isn't lack of understanding, it's just that *the
> arguments aren't convincing people*. Come up with new arguments, or
> accept that people don't agree with you. It's getting pretty hard to
> follow this discussion, simply because any genuinely new points are
> getting lost in a swamp of re-hashed explanations of arguments and
> suggestions that have already been made.
I am fully willing to accept that people don't think it's a good idea. I
spent time continuing to explain because it was actually clear that Steve,
at least, did not understand what the proposal on this thread actually was
until his most recent message. I'm sure that's mostly my fault.
Anyway, moving on from explaining what it is. I am not a person that
assumes my ideas are so fantastic that if people don't support them they
must not understand. On the contrary, I'm assuming my ideas probably aren't
good and if people don't like them I seek to understand why.
And everyone has been immensely helpful. The signature dependent semantics
idea I suggested on the other thread, for example, was rightly shot down
because it won't work with python's dynamic nature. So I abandoned it.
So I remain unimpressed by the bulk of the arguments here, and
> unconvinced that we need *any* of these proposals.
>
> Paul
>
Here's one reason I find a new dunder or dunders compelling that I haven't
seen anyone respond to directly:
I can write functions that define named arguments, and if I pass them
positionally, they get assigned the right name automatically (unless
disallowed by the signature using 3.8 positional only syntax):
def f(x, y): ...
f(1, 2)
f(1, y=2)
f(y=2, x=1)
If we add kwargs to the subscript operator, we'll be able to add new
required or optional names to item dunder signatures and supply named
arguments :
def __getitem__(self, key, x, y): ...
q[x=1, y=2]
But if we want to have the same behavior without supporting function style
syntax, we will have to write code like this:
MISSING = object()
def __getitem__(self, key, x=MISSING, y=MISSING):
if x is MISSING and y is MISSING::
x, y = key
if x is missing:
x, = key
if y is MISSING:
y, = key
And probably that code I just wrote has bugs. And it gets more complicated
if we want to have more arguments than just two. And even more complicated
if we want some of the arguments to be positional only or any other
combination of things.
This is code you would not have to write if we could do this instead with a
new dunder or subscript processor:
def __getx__(self, x, y): ...
And these all just work:
q[1, 2]
q[1, y=2]
q[y=2, x=1]
1 is assigned to x and 2 is assigned to y in all of these for both
versions, but the second certain requires not parsing of parameters. Python
does it for us. That's a lot of easily available flexibility.
_______________________________________________
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/M73XGYBTY4KVX7CZSS2FXKDQ6RAPOO2V/
Code of Conduct: http://python.org/psf/codeofconduct/
