On Wed, Aug 5, 2020, 09:47 Ricky Teachey <ri...@teachey.org> wrote:
> Hi Todd thanks for your response.
>
> On Tue, Aug 4, 2020 at 11:01 AM Todd <toddr...@gmail.com> wrote:
>
>> On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey <ri...@teachey.org> wrote:
>>
>>> ...
>>>
>>> There could be several reasons for changing the item dunder signatures.
>>> The immediate reason is making the intuition around how to add kwd arg
>>> support to square brackets more obvious and sane.
>>>
>>> A second reason is it might be more intuitive for users who have to
>>> learn and remember that multiple arguments to [ ] get packed into a tuple,
>>> but this doesn't happen anywhere else.
>>>
>>
>> My main issue with this is that, in my opinion, dunders are not something
>> a beginner should be messing with anyway. By the time someone is
>> experienced enough to start working on this, they are also experienced
>> enough to understand that special cases like this exist for historical
>> reasons.
>>
>
> Yeah I understand and agree but even non-beginners benefit a lot from
> having consistent behaviors in the language, and not having to remember
> exceptions.
>
But it isn't really an exception. Lots of arguments accept sequences of
various types. It doesn't take full advantage of what the language can do,
but it also isn't inconsistent with the language.
Any change has to balanced against the cost of rewriting every textbook and
tutorial on the subject. Adding labelled indexes wouldn't be as much of an
issue since nobody who doesn't need it needs to think about it. But
changing the default dunder signature is something everyone dealing with
those dunder methods would need to deal with.
As for my specific idea of how to accomplish the signature change, it's
> true that adding replacement getx/setx/delx dunders to the language would
> in fact be *additional* things to remember, not *fewer *things. But the
> goal would be to eventually replace getitem/setitem/delitem-- so this would
> be a temporary situation and eventually go away. Similar to how most people
> don't have a daily need to remember any number of old, previously standard
> and important, ways of doing things after a few years of transition.
>
The problem is backwards-compatibility. The current solution isn't going
to go away any time soon, if ever. It is too fundamental to the language
to change. The time to do that would have been the python 2-to-3 switch.
Nothing like that is planned.
>
>> Another reason: it could make writing code for specialized libraries
>> that tend to abuse (for the good of us all!) item dunders, like pandas,
>> much easier. Right now such libraries have to rely on their own efforts to
>> break up a key:
>>
>>>
>>> def __getitem__(self, key):
>>> try:
>>> k1, k2 = key
>>> except TypeError:
>>> raise TypeError("two tuple key required")
>>>
>>> But for regular function calls (as opposed to item getting) we get to
>>> write our signature however we want and rely on the language to handle all
>>> of this for us:
>>>
>>> def f(k1, k2):
>>> # no worries about parsing out the arguments
>>>
>>
>> But this is still a pretty simple piece of code. Is it worth having
>> everyone start over from scratch to avoid dealing with 4 lines of code?
>> Especially since knowing the number of indices ahead of time is a special
>> case for a small number of projects like pandas. In most cases, the number
>> of indices cannot be known until runtime, so this would provide no
>> practical benefit for most projects.
>>
>>
>
> This alone wouldn't be enough of a benefit, I agree. I find the combined
> benefits taken together compelling enough to at least warrant the
> exploration.
>
I guess that is where we disagree. I don't see the advantages as all that
large compared to the disadvantage of everyone having to deal with two
implementations, perhaps for decades.
>
>> -----------
>>>
>>> One idea: change the "real" names of the dunders. Give `type` default
>>> versions of the new dunders that direct the call to the old dunder names.
>>> ...
>>>
>>> However the set dunder signature would be a problem, because to mirror
>>> the current behavior we end up writing what is now a syntax error:
>>>
>>> def __setx__(self, /, *__key, __value, **__kwargs):
>>> self.__setitem__(__key, __value, **__kwargs)
>>>
>>> The intended meaning above would be that the last positional argument
>>> gets assigned to __value. Maybe someone could suggest a way to fix this.
>>>
>>
>> The simplest way would be to put "value" first:
>>
>> def __setx__(self, __value, /, *__key, **__kwargs):
>>
>
> I didn't mention that as an option because-- since we are dealing with
> positional only arguments much of the time-- it could become very confusing
> to switch the order of the key and value arguments in actual code.
>
More confusing than changing from a tuple to separate arguments, with
specific requirements for where the ”/” must go for it to work? I think if
they are making such a big switch already, the order of the arguments is a
relatively small change.
But if that is the case then the __setx__ hurdle appears insurmountable,
> apart from modifying the language so that function signatures can behave
> similar to this syntax feature:
>
> first, *rest, last = [1, 2, 3, 4, 5, 6]
> assert first == 1
> assert last == 6
> assert rest == [2, 3, 4, 5]
>
> ... so then you could write a function signature in this way:
>
> def f(first, *rest, last, /):
> return first, rest, last
>
> first, rest, last = f(1, 2, 3, 4, 5, 6)
> assert first == 1
> assert last == 6
> assert rest == [2, 3, 4, 5]
>
> So I suppose that would be yet another change that would need to happen
> first.
>
Yes, that is a completely different discussion.
>
_______________________________________________
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/HWUPYBHCRFW2ZHENBXTOHXZYANPOKSQN/
Code of Conduct: http://python.org/psf/codeofconduct/
