On Sat, 29 Aug 2020 at 05:53, Ricky Teachey wrote:
>
> On Fri, Aug 28, 2020 at 10:10 PM Steven D'Aprano wrote:
>> So let me see if I have this. You want to add a special dunder method
>> which, if it exists, is automatically called by the interpreter to
>> preprocess the subscript before passing
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]
print(a.argmax()) # 1
print(a.argmin()) # 0
It's a very popular request (based on stackoverflow
https://stackoverflow.com/
> 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]
> print(a.argmax()) # 1
> print(a.argmin()) # 0
>
> It
On Sat, Aug 29, 2020, 5:08 AM Paul Moore 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 und
For me, a satisfactory outcome from the current PEP process would be a new
dunder, which I am calling __keyfn__, that has two possible values,
namely None or True. (And of course, the associated syntax and semantics
changes. And documentation changes. These are not minor matters.)
As __keyfn__ has
On Sat, 29 Aug 2020 at 15:12, Ricky Teachey wrote:
>
> 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::
>
I wrote:
Ricky has given some examples. Here are more, all assuming
> __keyfn__ = True
>
My mistake. It should be
__keyfn__ = None
I'm sure you've already figured that out. Still, please accept my apologies.
--
Jonathan
>
___
Python-ideas ma
On Sat, 29 Aug 2020 at 15:12, Ricky Teachey wrote:
> 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 automatica
Paul Moore wrote:
But you don't give any reason why you'd want to do that. Why are you
> using subscript notation rather than a simple function call?
Good point. Consider
>>> def f(*argv): pass
>>> d = dict()
Now compare
>>> f(1, 2) = 3
SyntaxError: can't assign to function call
So __keyfn__ has literally only two allowed values, None and True. Can you
explain (in words or with examples) what happens in each case? You were so
excited to show off one case that you never showed how the other case would
work (and you tripped up over the value of __keyfn__ that you were
demons
Thank you, Guido, for your interest in this discussion.
You wrote:
> So __keyfn__ has literally only two allowed values, None and True.
>
That's my proposal, for now. I'm happy for further allowed values to be
added via another PEP. In fact, that is my preference.
You also wrote:
> Could you j
On Sat, Aug 29, 2020, 11:42 AM Jonathan Fine wrote:
> For me, a satisfactory outcome from the current PEP process would be a new
> dunder, which I am calling __keyfn__, that has two possible values,
> namely None or True. (And of course, the associated syntax and semantics
> changes. And document
On Sat, 29 Aug 2020 at 18:04, Jonathan Fine wrote:
>
> Paul Moore wrote:
>
>> But you don't give any reason why you'd want to do that. Why are you
>> using subscript notation rather than a simple function call?
>
>
> Good point. Consider
> >>> def f(*argv): pass
> >>> d = dict()
>
> Now co
Paul Moore wrote:
Again, obvious. But you still haven't given any reason why we would want to
> do that. No-one's arguing that these things aren't possible, or that the
> proposals can't be implemented. What I'm asking, and you aren't answering,
> is what is the use case? When, in real world code,
On Sat, Aug 29, 2020, 2:24 PM Paul Moore wrote:
> On Sat, 29 Aug 2020 at 18:04, Jonathan Fine wrote:
> >
> > Paul Moore wrote:
> >
> >> But you don't give any reason why you'd want to do that. Why are you
> >> using subscript notation rather than a simple function call?
> >
> >
> > Good point. C
On Sat, Aug 29, 2020 at 11:04 AM Jonathan Fine wrote:
[snip]
> The passage
> >>> d[1, 2] = 'val'
> >>> d.__setitem__((1,2), 'val')
> goes via tuple. If tuple didn't already exist, we'd have to invent it. And
> so here tuple is what I call "the key function".
>
IIUC in order to get these
On Sat, Aug 29, 2020 at 4:08 PM Guido van Rossum wrote:
> [...]
> Finally, I am unsure how you would deal with the difference between d[1]
> and d[1,], which must be preserved (for `__keyfn__ = True` or absent, for
> backwards compatibility). The bytecode compiler cannot assume to know the
> valu
On 30/08/20 3:49 am, Adam Johnson wrote:
def _parse_subscripts(self, /, x, y):
return x, y
def __getitem__(self, item=MISSING, /, **kwargs):
if item is MISSING:
args = ()
elif isintance(item, tuple):
args = item
else:
args = (item,)
x, y = sel
On Sat, Aug 29, 2020 at 12:50:15AM -0400, Ricky Teachey wrote:
> I was really trying to explain the semantics multiple times but as I look
> over my messages your criticism is correct, I was throwing out too many
> detailed examples rather than focusing on the idea.
Also there are so many differe
On Sat, Aug 29, 2020 at 04:31:53PM -0700, Guido van Rossum wrote:
> On Sat, Aug 29, 2020 at 4:08 PM Guido van Rossum wrote:
>
> > [...]
> > Finally, I am unsure how you would deal with the difference between d[1]
> > and d[1,], which must be preserved (for `__keyfn__ = True` or absent, for
> > ba
On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote:
> >So if you want to accept keywords, you just add keywords to your
> >existing dunder method. If you don't want them, don't add them. We don't
> >need a new dunder just for the sake of keywords.
>
> Nobody disputes that it *could* be ma
On Sat, Aug 29, 2020, 10:30 PM Steven D'Aprano wrote:
> I expect that the first will be the most common. If we add a keyword to
> the subscript:
>
> obj[1, a=3]
>
> I would expect that the it turns into `__getitem__(1, a=3)` which is
> almost surely what the reader and coder expects. It would
On Sat, Aug 29, 2020 at 07:22:52PM +0100, Paul Moore wrote:
> > Item assignment (ie __setitem__) is the one thing that a function call
> > can't do. If we want keywords in our __getitem__ and so on commands, then
> > one route for item assignment is to allow
> > >>> d[1, 2, a=3, b=4] = 5
> >
On 30/08/20 2:10 pm, Steven D'Aprano wrote:
> I wrote:
So
I'd be fine with having to write a[(1,)] to get a one-element tuple in both
the old and new cases.
But the problem is that this is a change in behaviour,
Sorry, I got that backwards! What I should have said was that a[1,]
would continu
On Sat, Aug 29, 2020 at 7:30 PM Steven D'Aprano wrote:
> I don't think that anyone wants adding a keyword to a single-valued
> subscript to change it to a tuple. At least, I really hope that nobody
> wants this!
>
> So given the current behaviour:
>
> obj[1] # calls __getitem__(1)
> obj[
On 30/08/20 3:06 pm, Steven D'Aprano wrote:
On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote:
a[17, 42]
a[time = 17, money = 42]
a[money = 42, time = 17]
I don't think that something like that is exactly the intended use-case
for the feature,
I don't see why we need to
On Sat, Aug 29, 2020, at 10:12, Ricky Teachey wrote:
> 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
27 matches
Mail list logo
