On Fri, Aug 7, 2020 at 6:02 PM Greg Ewing
wrote:
> On 4/08/20 9:12 am, Guido van Rossum wrote:
> > then presumably calling `c[1, index=2]` would just be an error (since it
> > would be like attempting to call the method with two values for the
> > `index` argument),
>
> Hmmm, does this mean that
On 4/08/20 9:12 am, Guido van Rossum wrote:
then presumably calling `c[1, index=2]` would just be an error (since it
would be like attempting to call the method with two values for the
`index` argument),
Hmmm, does this mean that classes providing index notation would
now need to document the
On 2020-08-07 13:13, Jonathan Fine wrote:
We are discussing a proposal to extend Python's syntax to allow
d[1, 2, a=3, b=4]
We are also discussing the associated semantics. At present
d[1, 2]
d[(1, 2)]
are semantically equivalent.
Python behaves as though it's wrapping
Jonathan, I took a look at your package, and the code, it's a really nice
exploration of the solutions.
I did find having to include the o() call in the sdaprano version quite
distracting (I realise it's needed to get it to work in current cpython
without silly tricks in the interpreter)...
On Fri, 7 Aug 2020 at 14:14, Jonathan Fine wrote:
> At present
> d[1, 2]
> d[(1, 2)]
> are semantically equivalent.
>
> There is a proposal, that
> d[1, 2, a=3, b=4]
> d[(1, 2), a=3, b=4]
> be semantically equivalent.
>
> I find this troubling, for example because
>fn(1, 2,
We are discussing a proposal to extend Python's syntax to allow
d[1, 2, a=3, b=4]
We are also discussing the associated semantics. At present
d[1, 2]
d[(1, 2)]
are semantically equivalent.
There is a proposal, that
d[1, 2, a=3, b=4]
d[(1, 2), a=3, b=4]
be semantically
On Thu, Aug 06, 2020 at 02:46:01PM +0100, MRAB wrote:
> On 2020-08-06 14:16, Stestagg wrote:
> > In the "New syntax", wouldn't these examples map to:
> >
> > d[1, 2, a=3] => d.__getitem__((1, 2), a=3)
> > and
> > d[(1, 2), a=3] => d.__getitem__((1, 2), a=3)
That is certainly what I would
Ok so let's do it like this. I'll open a PR against the PEP and I will
aggregate all the feedback from this discussion as additional notes.
I'll have to re-read the PEP myself, It's been a while.
As I said, I'm swamped so I might start working on it probably on Monday.
On Wed, 5 Aug 2020 at
Yes fair point.
That seems more correct
On Thu, Aug 6, 2020 at 2:49 PM MRAB wrote:
> On 2020-08-06 14:16, Stestagg wrote:
> > I was following you right up till this bit:
> >
> >
> > By the way, as previously noted
> > d[1, 2]
> > d[(1, 2)]
> > are at present
On 2020-08-06 14:16, Stestagg wrote:
I was following you right up till this bit:
By the way, as previously noted
d[1, 2]
d[(1, 2)]
are at present equivalent. However, in the new syntax
d[1, 2, a=3]
d[(1, 2), a=3]
are not equivalent. (The first
I was following you right up till this bit:
>
> By the way, as previously noted
> d[1, 2]
> d[(1, 2)]
> are at present equivalent. However, in the new syntax
> d[1, 2, a=3]
> d[(1, 2), a=3]
> are not equivalent. (The first has three arguments, the second two, the
> first of which
Hi Todd
You wrote:
I guess the thing I don't understand is why you favor that API. Could you
> please explain what you think are the advantages of your approach, ideally
> with some examples where you think your approach is clearer?
>
I've created a github issue for this, which I'll answer
On Wed, Aug 5, 2020 at 3:01 PM Stefano Borini
wrote:
> Maybe I should open a new PEP?
>
I"ll let teh PEP editors decide, but it look slike it was "rejected"m with
this comment:
"The idea never seemed to gain any traction over its near 5 years in
existence as a PEP."
So I'd think re-opening
I am following, but very swamped with work so I am kind of to the side
for a few more days.
I am thinking about looking for a sponsor for the PEP, but at this
point it's better if I rework the current analysis in light of what
you made and the current discussion. Maybe I should open a new PEP?
On
On Mon, Aug 3, 2020 at 1:58 PM Jonathan Fine wrote:
> The decorator key_to_jfine comes from the kwkey.jfine submodule. It
> implements the API that I favour. This is my first contribution to the
> exploration of the API.
>
>
I guess the thing I don't understand is why you favor that API. Could
Thank you all for your posts. I'm busy now and for the next few days, so
have little time to respond. Here's some comments and suggestions.
I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan will
take a special interest in this post. In the previous thread, these people
saw
The primary issue I was trying to find a way to reliably and clearly avoid
conflicts between the index labels and the positional argument names. So
if you have:
__getitem__(self, index, **kwargs)
You can't have an index label named "index", because it conflicts with the
"index" positional
On 4/08/20 1:16 pm, Steven D'Aprano wrote:
Why would we want to even consider a new approach to handling keyword
arguments which applies only to three dunder methods, `__getitem__`,
`__setitem__` and `__delitem__`, instead of handling keyword arguments
in the same way that every other method
On 4/08/20 6:35 pm, Greg Ewing wrote:
Has anyone suggested attaching the keyword args as attributes
on the slice object?
Realised after sending that this idea is rubbish, because
there can be more than one slice object.
--
Greg
___
Python-ideas
On 4/08/20 9:20 am, Todd wrote:
Another approach could be too simply pass the labelled indices in a dict
as a third/fourth positional argument.
Has anyone suggested attaching the keyword args as attributes
on the slice object?
This would avoid changing the signature of __getitem__, and
On Mon, Aug 03, 2020 at 05:20:25PM -0400, Todd wrote:
> Another approach could be too simply pass the labelled indices in a dict as
> a third/fourth positional argument.
Why would we want to even consider a new approach to handling keyword
arguments which applies only to three dunder methods,
On Mon, Aug 03, 2020 at 05:51:58PM -0400, Ricky Teachey wrote:
> However I'll also point out that another idea from Jonathan Fine has the
> potential to fix both this problem and the key object signature problem,
> which is what he called a "SIGNATURE CHANGING ADAPTER".
>
>
> > Here's how it
On Mon, Aug 3, 2020 at 2:35 PM Todd wrote:
> On Mon, Aug 3, 2020, 17:13 Guido van Rossum wrote:
>
>> On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
>> wrote:
>>
>>>
>>> Yes, that would be correct. However, the function could instead be
defined as:
def __getitem__(self, index,
On Mon, Aug 3, 2020 at 5:23 PM Todd wrote:
> Another approach could be too simply pass the labelled indices in a dict
> as a third/fourth positional argument.
>
> So for indexing
>
> b = arr[1, 2, a=3, b=4]
>
> Instead of
>
> __getitem__(self, (1, 2), a=3, b=4)
>
> Just do
>
> __getitem__(self,
On Mon, Aug 3, 2020, 17:13 Guido van Rossum wrote:
> On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
> wrote:
>
>>
>> Yes, that would be correct. However, the function could instead be
>>> defined as:
>>>
>>> def __getitem__(self, index, /, **kwargs):
>>> ...
>>>
>>> and then there'd be
Another approach could be too simply pass the labelled indices in a dict as
a third/fourth positional argument.
So for indexing
b = arr[1, 2, a=3, b=4]
Instead of
__getitem__(self, (1, 2), a=3, b=4)
Just do
__getitem__(self, (1, 2), {'a': 3, 'b': 4})
On Mon, Aug 3, 2020, 16:46 Christopher
On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
wrote:
>
> Yes, that would be correct. However, the function could instead be defined
>> as:
>>
>> def __getitem__(self, index, /, **kwargs):
>> ...
>>
>> and then there'd be no conflict (as "self" and "index" must be passed
>> positionally).
> Yes, that would be correct. However, the function could instead be defined
> as:
>
> def __getitem__(self, index, /, **kwargs):
> ...
>
> and then there'd be no conflict (as "self" and "index" must be passed
> positionally). In effect, the naive spelling (which permits self and
> index to be
On Tue, Aug 4, 2020 at 4:38 AM Todd wrote:
>
> One potential issue with this approach just occurred to me. I apologise if
> my thinking on this is wrong.
>
> Say a project implements __getitem__ with the signature
>
> __getitem__(self, index, **kwargs)
>
> Doesn't that mean that a "index" will
One potential issue with this approach just occurred to me. I apologise if
my thinking on this is wrong.
Say a project implements __getitem__ with the signature
__getitem__(self, index, **kwargs)
Doesn't that mean that a "index" will not be an allowable index label, and
that this conflict will
Hi Todd
You wrote:
> Do we have an agreement on the API as Guido requested? From my
> understanding, and please correct me if I am wrong, you are still talking
> about implementing this using a new class. However, most people who
> support the use of labelled indexing.and expressed an opinion
I wasn't saying you had agreed to anything, I was saying you requested that
others agree on an API before trying to implement a prototype of it ("It
would help if someone looked into a prototype implementation as well (once
a design has been settled on).").
Jonathan seems to be going ahead with
On Mon, Aug 3, 2020 at 1:10 PM Jonathan Fine wrote:
> SUMMARY:
> Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.
>
> This package is about PEP 472 -- Support for indexing with keyword
> arguments
> See: https://www.python.org/dev/peps/pep-0472/
>
> As a result, I think
I haven't agreed to anything. Though last time I thought about this I was
in favor of Steven D'Aprano's idea of translating `x[1, 2, p=3, q=4]` into
`x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__`
would do with that is a different issue -- probably it would be an error.
On
On Mon, Aug 3, 2020, 13:11 Jonathan Fine wrote:
> SUMMARY:
> Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.
>
> This package is about PEP 472 -- Support for indexing with keyword
> arguments
> See: https://www.python.org/dev/peps/pep-0472/
>
> As a result, I think we're
35 matches
Mail list logo
