On Mon, 20 Jul 2020 at 03:26, Jonathan Goble wrote:
>> One use case that comes up in xarray and pandas is support for indicating
>> indexing "modes". For example, when indexing with floating point numbers
>> it's convenient to be able to opt-in to approximate indexing, e.g.,
>> something like:
On Fri, 17 Jul 2020 at 20:58, Christopher Barker wrote:
> So what would the “key object” be I the proposed case:
>
> d2[a=1, b=2]
>
> A namedtuple? Or namedtuple-like object?
This was already discussed in PEP-472 as the "namedtuple" strategy,
but among the various negative points were the
As I said I would, I've now published a package on PyPI to support our
exploration and development of this idea.
You'll find more information on this new thread:
Subject: Package kwkey and PEP 472 -- Support for indexing with keyword
arguments
URL:
On Tue, Jul 21, 2020 at 2:05 PM David Mertz wrote:
> On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg
>
>> First, using it for named dimensions, means you don't actually need to
>> mix it with normal tuple indexing, mixing both seems rather confusing?
>>
>>
On Sat, Jul 18, 2020, 00:21 Ricky Teachey wrote:
>
> This raises a question that needs to be answered, then: what would be the
> utility of mixing together positional and kwd arguments in this way?
>
> Even the xarray examples given so far don't seem to make use of this
> mixture. From my
Relevant to Jonathan's suggestion for a "key-object", Marco has been
performing some experiments on an immutable dict:
https://mail.python.org/archives/list/python-ideas@python.org/message/K7CRVW6O7RO6DT3JIG3OAJCAVCA5CNTN/
--
Steven
___
Python-ideas
On Tue, Jul 21, 2020 at 9:15 AM Sebastian Berg
wrote:
> On Mon, 2020-07-20 at 22:27 -0700, Christopher Barker wrote:
> > On Mon, Jul 20, 2020 at 3:17 AM Rhodri James
> > wrote:
> >
> > > Ironically that example pushes me back to -1. It may look a lot
> > > like
> > > xarray and pandas working,
On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg
> First, using it for named dimensions, means you don't actually need to
> mix it with normal tuple indexing, mixing both seems rather confusing?
>
> temperature.loc(method="nearest")[longitude=longs, latitude=lats]
>
I probably don't disagree on
On Mon, 2020-07-20 at 22:27 -0700, Christopher Barker wrote:
> On Mon, Jul 20, 2020 at 3:17 AM Rhodri James
> wrote:
>
> > Ironically that example pushes me back to -1. It may look a lot
> > like
> > xarray and pandas working, but that just means it should be in
> > xarray
> > and/or pandas.
>
You have to find a core dev who is willing to act as a Sponsor. I recommend
asking Steven d’Aprano (but I do not know if he’s interested). Until then,
hash out the precise spec for the idea here. Coming up with a solid
motivation is also important.
On Tue, Jul 21, 2020 at 01:15 Stefano Borini
On Tue, Jul 21, 2020, 5:48 AM Gerrit Holl wrote:
> On Sat, 18 Jul 2020 at 18:31, MRAB wrote:
> > [snip]
> > I haven't followed this thread for a while, but, to me, it seems that
> > the simplest option would be to pass the keyword arguments as a dict:
> >
> > obj[a, b:c, x=1] does
On Sat, 18 Jul 2020 at 18:31, MRAB wrote:
> [snip]
> I haven't followed this thread for a while, but, to me, it seems that
> the simplest option would be to pass the keyword arguments as a dict:
>
> obj[a, b:c, x=1] does obj.__getitem__((a, slice(b, c)), dict(x=1))
>
> If there are no
On Mon, 20 Jul 2020 at 04:27, Jonathan Goble wrote:
>> One use case that comes up in xarray and pandas is support for indicating
>> indexing "modes". For example, when indexing with floating point numbers
>> it's convenient to be able to opt-in to approximate indexing, e.g.,
>> something like:
I am unsure of the process if there's interest. Should I revise the
PEP and create a new one?
On Tue, 21 Jul 2020 at 06:29, Christopher Barker wrote:
>
> On Mon, Jul 20, 2020 at 3:17 AM Rhodri James wrote:
>>
>> Ironically that example pushes me back to -1. It may look a lot like
>> xarray and
On Mon, Jul 20, 2020 at 3:17 AM Rhodri James wrote:
> Ironically that example pushes me back to -1. It may look a lot like
> xarray and pandas working, but that just means it should be in xarray
> and/or pandas.
after following most of this discussion, I'm still not sure what we'd get
with
On 20/07/2020 06:11, Ricky Teachey wrote:
On Sun, Jul 19, 2020 at 9:53 PM Stephan Hoyer wrote:
One use case that comes up in xarray and pandas is support for indicating
indexing "modes". For example, when indexing with floating point numbers
it's convenient to be able to opt-in to approximate
On Sun, Jul 19, 2020 at 9:53 PM Stephan Hoyer wrote:
> On Fri, Jul 17, 2020 at 9:22 PM Ricky Teachey wrote:
>
>> >>> # The positional arguments aren't part of the KeyObject
>> >>> d[a, b:c, d, e=5, f=6] == d.__getitem__((a, b:c, d), KeyObject(e=5,
>> f=6))
>>
>> This raises a question that
On Sun, Jul 19, 2020 at 10:27 PM Jonathan Goble wrote:
> One use case that comes up in xarray and pandas is support for indicating
>> indexing "modes". For example, when indexing with floating point numbers
>> it's convenient to be able to opt-in to approximate indexing, e.g.,
>> something like:
On Sun, Jul 19, 2020 at 10:25 PM Jonathan Goble wrote:
> On Sun, Jul 19, 2020 at 9:53 PM Stephan Hoyer wrote:
>
>> On Fri, Jul 17, 2020 at 9:22 PM Ricky Teachey wrote:
>>
>>> >>> # The positional arguments aren't part of the KeyObject
>>> >>> d[a, b:c, d, e=5, f=6] == d.__getitem__((a, b:c,
On Sun, Jul 19, 2020 at 10:24:42PM -0400, Jonathan Goble wrote:
> IMHO the above example would be better spelled as:
>
> array.loc.get(longitude, latitude, method='nearest', tolerance=0.001)
One of the use-cases for this is for type hints, where you cannot use
method calls. So that's right
On Sun, Jul 19, 2020 at 9:53 PM Stephan Hoyer wrote:
> On Fri, Jul 17, 2020 at 9:22 PM Ricky Teachey wrote:
>
>> >>> # The positional arguments aren't part of the KeyObject
>> >>> d[a, b:c, d, e=5, f=6] == d.__getitem__((a, b:c, d), KeyObject(e=5,
>> f=6))
>>
>> This raises a question that
On Fri, Jul 17, 2020 at 9:22 PM Ricky Teachey wrote:
> >>> # The positional arguments aren't part of the KeyObject
> >>> d[a, b:c, d, e=5, f=6] == d.__getitem__((a, b:c, d), KeyObject(e=5,
> f=6))
>
> This raises a question that needs to be answered, then: what would be the
> utility of mixing
On 7/19/2020 6:49 PM, David Mertz wrote:
On Sun, Jul 19, 2020 at 6:35 PM Dominik Vilsmeier
mailto:dominik.vilsme...@gmx.de>> wrote:
But this looks unnecessarily complicated. Why can't xarray allow
the following:
ds["empty"]["lon", 1:5, "lat", 3:] = 10
which looks very
On Sun, Jul 19, 2020 at 6:35 PM Dominik Vilsmeier
wrote:
> But this looks unnecessarily complicated. Why can't xarray allow the
> following:
>
> ds["empty"]["lon", 1:5, "lat", 3:] = 10
>
> which looks very close to the proposed syntax below. Not that I'm against
> the proposal but I think
On 17.07.20 22:11, Todd wrote:
On Fri, Jul 17, 2020 at 12:19 PM David Mertz mailto:me...@gnosis.cx>> wrote:
Fwiw, I'm probably -0 on the feature itself. Someone suggested it
could be useful for xarray, but I'm not sure now what that would
look like. If someone had an example, I
On Sat, Jul 18, 2020 at 9:11 PM Christopher Barker
wrote:
>
>
> On Sat, Jul 18, 2020 at 1:43 PM Guido van Rossum wrote:
>
>> Yes please.
>>
>
> Yes to what, exactly?
>
> -CHB
>
> FWIW, IIRC the “bundle values in a single parameter” predates the demise
>> of __getslice__. It probably was meant
On Sat, Jul 18, 2020 at 1:43 PM Guido van Rossum wrote:
> Yes please.
>
Yes to what, exactly?
-CHB
FWIW, IIRC the “bundle values in a single parameter” predates the demise of
> __getslice__. It probably was meant for dict keys primarily (no surprise
> there). The bundling would have been
Yes please.
FWIW, IIRC the “bundle values in a single parameter” predates the demise of
__getslice__. It probably was meant for dict keys primarily (no surprise
there). The bundling would have been easier for the C API — __getitem__ is
as old as Python there.
On Sat, Jul 18, 2020 at 10:49 Steven
On Sat, Jul 18, 2020 at 05:30:40PM +0100, MRAB wrote:
> I haven't followed this thread for a while, but, to me, it seems that
> the simplest option would be to pass the keyword arguments as a dict:
What are you going to do with that keyword argument dict?
Most use-cases I can think of will
On 2020-07-18 10:04, Steven D'Aprano wrote:
On Sat, Jul 18, 2020 at 12:18:38AM -0400, Ricky Teachey wrote:
On Fri, Jul 17, 2020 at 7:21 PM Steven D'Aprano wrote:
> On Fri, Jul 17, 2020 at 11:11:17AM -0400, Ricky Teachey wrote:
>
> ...
>
> For backwards-compatibility, there will only ever be a
Andras Tantos wrote
>
> Thanks for picking up on this thread, I almost given up hope that
> anyone would be interested. Then it suddenly blew up :)!
to thank all who expressed interest and support. (Andras means 'blew up' in
a good way!)
And I thank you, Andras. It's nice to be appreciated. I
On Sat, Jul 18, 2020 at 12:18:38AM -0400, Ricky Teachey wrote:
> On Fri, Jul 17, 2020 at 7:21 PM Steven D'Aprano wrote:
>
> > On Fri, Jul 17, 2020 at 11:11:17AM -0400, Ricky Teachey wrote:
> >
> > ...
> >
> > For backwards-compatibility, there will only ever be a single positional
> > argument
On Fri, Jul 17, 2020 at 7:21 PM Steven D'Aprano wrote:
> On Fri, Jul 17, 2020 at 11:11:17AM -0400, Ricky Teachey wrote:
>
> ...
>
> For backwards-compatibility, there will only ever be a single positional
> argument passed into the method. That's because comma-separated values
> in a subscript
On Fri, Jul 17, 2020 at 11:11:17AM -0400, Ricky Teachey wrote:
> It seems to me that the validity of this key-object paradigm is directly
> tied to the decision of whether or not to change the get/set item dunder
> signatures.
But note that even if we allow keyword args in subscripts, we still
Jonathan and all!
Thanks for picking up on this thread, I almost given up hope that anyone
would be interested. Then it suddenly blew up :)!
Jonathan, your suggestion makes sense as a stop-gap measure for current
Python, but I'm unclear on the way forward to the new syntax:
When you say we
On 17/07/2020 21:11, Todd wrote:
On Fri, Jul 17, 2020 at 12:19 PM David Mertz wrote:
Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be
useful for xarray, but I'm not sure now what that would look like. If
someone had an example, I could easily be moved.
Here is
On Fri, Jul 17, 2020 at 4:12 PM Todd wrote:
> ds["empty"][lon=1:5, lat=6:] = 10
>
I agree that looks really nice. I think this is the first suggestion to
allow slices on the RHS of keyword indexing. That's the part that was
missing in me understanding how this would help xarray greatly. It's
On Fri, Jul 17, 2020 at 12:19 PM David Mertz wrote:
> Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be
> useful for xarray, but I'm not sure now what that would look like. If
> someone had an example, I could easily be moved.
>
Here is what it currently looks like to
On Fri, Jul 17, 2020, 12:10 David Mertz wrote:
> On Fri, Jul 17, 2020, 8:16 AM Jonathan Fine wrote:
>
>> Steve and I have different opinions, as to what the new behaviour of:
>> >>> d = dict()
>> >>> d[x=1, y=2] = 3
>> should be.
>>
>> He prefers that the assignment fail with
>>
On Fri, Jul 17, 2020 at 11:49 AM Jonathan Fine wrote:
> I am able today to respond to one question. Ricky asked if
>>>> key_object = K(a=1, b=2) # where K is some new key object type
>>>> d1 = {key_object: 3}
>>>> d2 = {}
>>>> d2[a=1, b=2] = 3
>>>> assert d1==d2
> was what I
Thank you all, for your useful contributions. I particularly value the
insight you've given me regarding the experience that underlies your views.
I'll respond to your comments tomorrow.
I am able today to respond to one question. Ricky asked if
>>> key_object = K(a=1, b=2) # where K is some
On Fri, Jul 17, 2020 at 12:30 PM Christopher Barker
wrote:
> On Fri, Jul 17, 2020 at 9:20 AM David Mertz wrote:
>
>> Fwiw, I'm probably -0 on the feature itself. Someone suggested it could
>> be useful for xarray, but I'm not sure now what that would look like. If
>> someone had an example, I
On Fri, Jul 17, 2020 at 9:20 AM David Mertz wrote:
> Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be
> useful for xarray, but I'm not sure now what that would look like. If
> someone had an example, I could easily be moved.
>
agreed -- I can imagine the use case, but
Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be
useful for xarray, but I'm not sure now what that would look like. If
someone had an example, I could easily be moved.
I'm not against the original suggested use with type annotations, but I
also don't really care about
On Fri, Jul 17, 2020, 8:16 AM Jonathan Fine wrote:
> Steve and I have different opinions, as to what the new behaviour of:
> >>> d = dict()
> >>> d[x=1, y=2] = 3
> should be.
>
> He prefers that the assignment fail with
> TypeError: dict subscripting takes no keyword arguments
>
> I
On Fri, Jul 17, 2020, 6:17 AM Jonathan Fine wrote:
> Guido wrote:
>
>> I think it’s a reasonable idea and encourage you to start working on a
>> design for the API and then a PRP.
>>
>
> In this post, I explore how the new API might interact with dict objects.
> (I think PRP is a typo for PEP.)
Steve and I have different opinions, as to what the new behaviour of:
>>> d = dict()
>>> d[x=1, y=2] = 3
should be.
He prefers that the assignment fail with
TypeError: dict subscripting takes no keyword arguments
I prefer that the assignment succeed (and hence a new key-value pair is
On Fri, Jul 17, 2020 at 11:14:21AM +0100, Jonathan Fine wrote:
> So what should be the new behaviour of:
> >>> d = dict()
> >>> d[x=1, y=2] = 3
TypeError: dict subscripting takes no keyword arguments
Just because something is syntactically allowed doesn't mean it has to
be given a
Guido wrote:
> I think it’s a reasonable idea and encourage you to start working on a
> design for the API and then a PRP.
>
In this post, I explore how the new API might interact with dict objects.
(I think PRP is a typo for PEP.)
Here is an example of the present behaviour
>>> d = dict()
I think it’s a reasonable idea and encourage you to start working on a
design for the API and then a PRP. It would help if someone looked into a
prototype implementation as well (once a design has been settled on).
On Thu, Jul 16, 2020 at 03:31 Steven D'Aprano wrote:
> On Wed, Jul 15, 2020 at
On Fri, Jul 10, 2020, 12:44 Steven D'Aprano wrote:
> On Fri, Jul 10, 2020 at 02:48:31PM +0200, Alex Hall wrote:
>
> > I believe he was saying it would be weird if `d[1, 2]` called
> > `d.__getitem__((1, 2))` but `d[1, 2, x=3]` called `d.__getitem__(1, 2,
> > x=3)`. More generally, if
On Wed, Jul 15, 2020 at 11:09:42PM -0700, Caleb Donovick wrote:
> I have wanted this and suggested it before for use with typing.
Was Guido interested or did he reject the idea?
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To
Hello,
On Wed, 15 Jul 2020 23:09:42 -0700
Caleb Donovick wrote:
> I have wanted this and suggested it before for use with typing.
>
> Defining protocols is obnoxiously verbose for "struct" like data and
> keyword
> arguments to subscript could help alleviate that.
> I often want to write type
Hi Caleb
You wrote (call it FUTURE)
> def foo(x: Protocol[id=int, name=str]):
> bar(x)
> baz(x)
>
As you know, at present this causes a SyntaxError.
However (call it NOW)
def foo(x: Protocol[o(id=int, name=str])):
bar(x)
baz(x)
has no syntax error.
I'll
I have wanted this and suggested it before for use with typing.
Defining protocols is obnoxiously verbose for "struct" like data and
keyword
arguments to subscript could help alleviate that.
I often want to write type hint like this:
```
def foo(x: Protocol[id=int, name=str]):
bar(x)
On Fri, 10 Jul 2020 at 17:45, Steven D'Aprano wrote:
> I must admit I like the look of this, but I don't know what I would use
> it for.
It feels very much like the sort of "here's some syntax that might
match someone's mental model of something" that is common in languages
that focus on
On Fri, Jul 10, 2020 at 02:48:31PM +0200, Alex Hall wrote:
> I believe he was saying it would be weird if `d[1, 2]` called
> `d.__getitem__((1, 2))` but `d[1, 2, x=3]` called `d.__getitem__(1, 2,
> x=3)`. More generally, if `__getitem__` always receives a single positional
> argument now, it
On Fri, Jul 10, 2020 at 01:59:06PM +0100, Jonathan Fine wrote:
> I wrote: Let's proceed. We continue to use d = Dummy(). Given that
>>>> key = d[1, 2, 3, a=4, b=5]
> is allowed, what should we be able to say about the key. Clearly it should
> be an instance of a class and there should be
Hi Ricky
Thank you for your very helpful comment, which Paul has usefully amplified.
You wrote:
This is confusing to me because `my_mapping[1,2,3]` is already valid syntax
> equivalent to `my_mapping.__setitem__(my_mapping, (1,2,3))`. Wouldn't a
> change to translate the tuple into this K object
On Fri, 10 Jul 2020 at 15:23, Jonathan Fine wrote:
> With hindsight, I can see your difficulty. The original idea is to extend the
> syntax so that
> >>> m = MyMap()
> >>> m[1, 2, 3, a=4, b=5] = 'foobar'
> is allowed in some future version of Python.
>
> Python's syntax already allows:
>
> Let's assume MyMap does have a __setitem__ method. Extending what you
> pointed out, the assignment
> >>> m[K(1, 2, 3, a=4, b=5)] = 'foobar'
> will then be equivalent to
> >>> MyMap.__setitem__(m, k, 'foobar')
> where
> >>> k = K(1, 2, 3, a=4, b=5)
>
>
This is confusing to me
Hi Paul
I'm writing in response to one of your comments, all of which are useful.
Please forgive me, Paul, for not responding to the others in this message.
I wrote:
> Next, the implementation of such K-mappings. Here, K.set and K.get
> decorators will help. Something like (not tested):
>
On Fri, 10 Jul 2020 at 11:54, Jonathan Fine wrote:
> Let's proceed. We continue to use d = Dummy(). Given that
>>>> key = d[1, 2, 3, a=4, b=5]
> is allowed, what should we be able to say about the key. Clearly it should be
> an instance of a class, and there should be a way of creating
Hi
I will clarify my previous post, by making a stronger statement. Every
Python object is an instance of a class.
I wrote: Let's proceed. We continue to use d = Dummy(). Given that
>>> key = d[1, 2, 3, a=4, b=5]
is allowed, what should we be able to say about the key. Clearly it should
On Fri, Jul 10, 2020 at 2:33 PM Steven D'Aprano wrote:
> On Fri, Jul 10, 2020 at 11:52:19AM +0100, Jonathan Fine wrote:
>
> > FUTURE
> > Let's proceed. We continue to use d = Dummy(). Given that
> >>>> key = d[1, 2, 3, a=4, b=5]
> > is allowed, what should we be able to say about the
On Fri, Jul 10, 2020 at 08:23:09AM -0400, Ricky Teachey wrote:
> My mind instantly went to the idea of using this syntax as a way write
> single line mathematical function definitions:
>
> f[x, y] = x + y
This won't work, because the right hand side will be evaluated first.
The above is legal
I believe that one of the most popular Python domains that benefit from
"abusing" indexes is data analysis in the numpy/Pandas world.
I am not familiar enough with Pandas to make useful speculation on how
named indexes could enhance the usage of dataframes, - maybe someone more
familiar can
On Fri, Jul 10, 2020 at 11:52:19AM +0100, Jonathan Fine wrote:
> FUTURE
> Let's proceed. We continue to use d = Dummy(). Given that
>>>> key = d[1, 2, 3, a=4, b=5]
> is allowed, what should we be able to say about the key. Clearly it should
> be an instance of a class
That's not clear at
On Fri, Jul 10, 2020, 6:54 AM Jonathan Fine wrote:
> Hi All
>
> SUMMARY
> This is a longish post. It looks at the idea in general terms, and
> outlines a way to get the desired semantics (by not syntax) with Python as
> it is today. And this would be forward compatible with the new syntax, if
>
Hi All
SUMMARY
This is a longish post. It looks at the idea in general terms, and outlines
a way to get the desired semantics (by not syntax) with Python as it is
today. And this would be forward compatible with the new syntax, if
provided later.
PRESENT
I like the idea of allowing
>>> d[1,
What the future of this?
I looked at type annotations in networkx recently (
https://github.com/networkx/networkx/pull/4014), and I wanted to keep
things simple, so I proposed and implemented
Graph[NodeType]
However, I knew that they may ultimately want
Graph[NodeType, EdgeTypedDict,
I am one of the authors of the PEP. My problem was to deal with
natural notation in quantum chemistry mostly. It had no technical
purpose, but I still think it would open some interesting options.
The PEP was rejected mostly because of lack of interest.
On Mon, 4 May 2020 at 00:07, Andras Tantos
On Mon, May 4, 2020 at 10:03 Antoine Pitrou wrote:
> Of course, that's why I originally suggested that `Dict[...]` should be
> spelled `Dict(...)` instead.
...and we’d be hosed now with no path from Dict to dict.
> --
--Guido (mobile)
___
On Sun, 3 May 2020 14:58:41 -0700
Andras Tantos wrote:
>
> 1. With the recent type-hint support, the feature could be made way more
> descriptive if this PEP got implemented.
>
> For example, instead of doing the following:
>
> def func(in: Dict[str, int])
>
> one could
74 matches
Mail list logo
