[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sat, Aug 29, 2020 at 10:29 PM Guido van Rossum wrote: > FYI, Jonathan's post (once I "got" it) led me to a new way of reasoning > about the various proposals (__keyfn__, __subscript__ and what I will keep > calling "Steven's proposal") based on what the compiler and interpreter > need to do to

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

IMPORTANT CORRECTION! I was too eager to get to bed and made a mistake in the summary for the d[1, a=3] cases. The key here should be '1', not '(1,)'. On Sun, Aug 30, 2020 at 12:45 AM Guido van Rossum wrote: > A quick summary of the proposal at the pure Python level: > > ``` > d[1] -> d.__getite

[Python-ideas] Re: argmax and argmin to python list

On 29/08/2020 14:17, Barry Scott wrote: On 29 Aug 2020, at 13:42, Filipp Bakanov > wrote: I'd like to propose adding argmax and argmin functions to the python list. These functions return the index of a maximum / minimum element of the list. Eg: a = [1, 4, 2, 3] pri

[Python-ideas] Re: argmax and argmin to python list

> On 30 Aug 2020, at 09:03, Jeff Allen wrote: > > On 29/08/2020 14:17, Barry Scott wrote: >>> On 29 Aug 2020, at 13:42, Filipp Bakanov >> > wrote: >>> >>> I'd like to propose adding argmax and argmin functions to the python list. >>> These functions return the index

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 30/08/20 7:45 pm, Guido van Rossum wrote: Do we want to support d[**kwargs]? It can be done, alternatively we could just ask the user to write the __getitem__/__setitem__ call explicitly. I thought we usually discouraged directly calling dunders unless there's no alternative, because there

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

A thought just occurred to me. If we hadn't got rid of tuple unpacking in argument lists, we would have been able to write def __getitem__(self, (x, y, z), **kwds): ... -- Greg ___ Python-ideas mailing list -- [email protected] To uns

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

I've written a decorator to go along with Guido's proposed implementation, to make it easier to write item dunders that take positional args that can also be specified by keyword. #--- from inspect import signature def positional_indexing(m): def f(s

[Python-ideas] Re: argmax and argmin to python list

It's expected that python single iterating would be slower than two times C iterating. Nevertheless one time C iterating will be probably faster than a separate min + index. >> I think one would want argmin() and argmax() to work with general iterables How is it supposed to work with set or dict o

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 09:56:28PM +1200, Greg Ewing wrote: > A thought just occurred to me. If we hadn't got rid of tuple > unpacking in argument lists, we would have been able to write > > def __getitem__(self, (x, y, z), **kwds): > ... Indeed. Now that Python is moving to a PEG pa

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 8/30/2020 7:25 AM, Steven D'Aprano wrote: On Sun, Aug 30, 2020 at 09:56:28PM +1200, Greg Ewing wrote: A thought just occurred to me. If we hadn't got rid of tuple unpacking in argument lists, we would have been able to write def __getitem__(self, (x, y, z), **kwds): ... Indeed

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

I am going to put everything in the new PEP tonight. On Sun, 30 Aug 2020, 08:47 Guido van Rossum, wrote: > On Sat, Aug 29, 2020 at 10:29 PM Guido van Rossum > wrote: > >> FYI, Jonathan's post (once I "got" it) led me to a new way of reasoning >> about the various proposals (__keyfn__, __subscri

[Python-ideas] Re: argmax and argmin to python list

On 30/08/2020 09:51, Barry Scott wrote: >>> a.index(max(a)) 1 Barry This has the drawback of passing twice over the list. The following doesn't, but the complexity somewhat makes Filipp's point: >>> min((e, i) for i, e in enumerate(a))[1] 0 That is 4x slower then my code for 1,000,000 i

[Python-ideas] Re: argmax and argmin to python list

> On 30 Aug 2020, at 12:25, Filipp Bakanov wrote: > >  > It's expected that python single iterating would be slower than two times C > iterating. Nevertheless one time C iterating will be probably faster than a > separate min + index. > > >> I think one would want argmin() and argmax() to w

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

I recall a law from evolutionary biology that went something like “once a feature is gone it won’t evolve a second time (in the same species)”. I have no interest in restoring argument unpacking. On Sun, Aug 30, 2020 at 05:20 Eric V. Smith wrote: > On 8/30/2020 7:25 AM, Steven D'Aprano wrote: >

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

Guido van Rossum wrote: > > Do we want to support d[**kwargs]? It can be done, alternatively we could > just ask the user to write the __getitem__/__setitem__ call explicitly. > I think we should say no to d[*args], because that will just become > d[(args)], with awkward questions around what if a

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

You appear to be making a connection between star-args in a call and in a function definition. They are unrelated. The more I hear about this the more I favor not supporting it in the subscript syntax. On Sun, Aug 30, 2020 at 08:44 Joseph Martinot-Lagarde wrote: > Guido van Rossum wrote: > > > >

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Sun, 30 Aug 2020 at 04:09, Steven D'Aprano wrote: > > Nobody disputes that it *could* be made to work that way. But I'm > > not convinced that it's the *best* way for it to work. The killer > > argument in my mind is what you would have to do to make an object > > where all of the following ar

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 3:37 am, Guido van Rossum wrote: I recall a law from evolutionary biology that went something like “once a feature is gone it won’t evolve a second time (in the same species)”. I have no interest in restoring argument unpacking. That can't be an absolute law. If a species loses a f

[Python-ideas] Re: argmax and argmin to python list

On Sun, Aug 30, 2020 at 7:28 AM Barry wrote: > How is it supposed to work with set or dict or other iterables without > clear order? > > see the discussion in another recent thread about making dict indexable -- which looks like it's not going to happen. so no -- this should not work with genera

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sat, Aug 29, 2020, at 20:14, Greg Ewing wrote: > I think this could be done more simply as > > def __getitem__(self, index, **kwds): > self.real_getitem(*index, **kwds) > > def real_getitem(self, x, y): > ... > > The point about obscuring the signature still remain

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 4:58 PM Greg Ewing wrote: > On 31/08/20 3:37 am, Guido van Rossum wrote: > > I recall a law from evolutionary biology that went something like “once > > a feature is gone it won’t evolve a second time (in the same species)”. > > I have no interest in restoring argument unp

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 8:44 AM Joseph Martinot-Lagarde < [email protected]> wrote: > Guido van Rossum wrote: > > > > Do we want to support d[**kwargs]? It can be done, alternatively we could > > just ask the user to write the __getitem__/__setitem__ call explicitly. > > I think we should say

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 2:43 AM Greg Ewing wrote: > On 30/08/20 7:45 pm, Guido van Rossum wrote: > > I think we should say no to d[*args], because that will just become > > d[(*args)], > > Which is also equivalent to d[args]. But if we have d[**kwds] > without d[*args] I expect there will forever

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Mon, Aug 31, 2020 at 1:38 PM Random832 wrote: > Another concern is where a new setitem should put the value argument? i may > have missed something mentioning it, but I don't think I've seen a proposal > that goes into detail on that? Having the user define a __setitem__ that > calls the rea

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 8:36 PM Random832 wrote: > The thing that bothers me with new dunders is - can it be done in such a > way that *all* possible ways of calling it with only positional arguments > behave the same as presently when the old one is defined, and an intuitive > way with the new o

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 8:44 AM Joseph Martinot-Lagarde < [email protected]> wrote: > I hope I understood correctly because Mailman eats the * signs for > formatting, > I just realized that Mailman (or some other part of the email toolchain -- maybe GMail?) has apparently a handy (:-) feature

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Mon, Aug 31, 2020, at 00:26, Chris Angelico wrote: > Maybe I'm misreading this, but my understanding is that the definition > of the dunder is actually how it's called, not what its signature is. > The simplest and most obvious way to do it would be to have the > interpreter pass the value posit

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Mon, Aug 31, 2020, at 00:28, Guido van Rossum wrote: > On Sun, Aug 30, 2020 at 8:36 PM Random832 wrote: > > The thing that bothers me with new dunders is - can it be done in such a > > way that *all* possible ways of calling it with only positional arguments > > behave the same as presently w

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 21:58 Random832 wrote: > A new bytecode operation (we'll need one anyway, right?) Yes. which, in addition to passing in the positionals and the keywords, also > passes along the information of whether or not the subscript contents > consisted of precisely a single expre

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Sun, Aug 30, 2020 at 10:01 PM Random832 wrote: > > like `d[1,]` + keyword. > > perhaps, but I did have a thought after making that post. > > A new bytecode operation (we'll need one anyway, right?) which, in > addition to passing in the positionals and the keywords, also passes along > the inf

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 3:35 pm, Random832 wrote: x[(1,)] old arg=(1,); new args=((1,),)? > x[(1,2)] old arg=(1,2); new args=((1,2),)? No, I proposed *not* to do those -- putting parens around the arguments would continue to make no difference, regardless of which dunder was being called. Also, do we wa

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 31/08/20 4:11 pm, Guido van Rossum wrote: Can I write a.__getitem__((1, 2), k=3) and the function will see (i, j, k) == (1, 2, 3)? Yes. Okay, and if I write a.__getitem__((1, 3), k=2) will the function see the same thing? No, it will see (i, j, k) == (1, 3, 2). It's the same as if you w