On 04/10/2019 20:34, Caleb Donovick wrote:
While there is no restriction on passing dicts to getitem. Doing so tends
to be a bit ugly. I have two main use cases in mind for this syntax.
The first and perhaps the most obvious, is doing relational queries.
```
where_x_1 = db[x=1]
```
is more be
On Mon, Oct 7, 2019, at 09:22, Rhodri James wrote:
> On 04/10/2019 20:34, Caleb Donovick wrote:
> > The first and perhaps the most obvious, is doing relational queries.
> > ```
> > where_x_1 = db[x=1]
> > ```
> > is more beautiful than
> > ```
> > where_x_1 = db[dict(x=1)]
> > where_x_1 = db[{'x':
On Mon, Oct 7, 2019, at 09:22, Rhodri James wrote:
> > Allowing key value pairs in geitem need not change the interface of
> > getitem. All the key value pairs could be collected as a dict and passed
> > to getitem as the index.
>
> Um. Stop me if I'm wrong, but isn't that exactly a change to t
So, in short, your idea is to allow "=" signs inside `[]` get notation to
be translated
to dicts on the call, in the same way comma separated values are translated
to
tuples?
I see no backwards syntax incompatibility in that, and the
tuple-translation is
indeed quite a helper in many cases. The us
On 07/10/2019 14:56, Random832 wrote:
On Mon, Oct 7, 2019, at 09:22, Rhodri James wrote:
Allowing key value pairs in geitem need not change the interface of
getitem. All the key value pairs could be collected as a dict and passed
to getitem as the index.
Um. Stop me if I'm wrong, but isn't
In fact, that would be a cool feature for ORMs. IMHO instead of ugly call
chain with filters, slicing is a better option (on `__class_getattr__`). As
said there are some disadvantages but i think this proposal deserves a PEP.
On Fri, Oct 4, 2019, 10:59 PM Caleb Donovick
wrote:
> While there is n
On 07/10/2019 14:52, Random832 wrote:
On Mon, Oct 7, 2019, at 09:22, Rhodri James wrote:
On 04/10/2019 20:34, Caleb Donovick wrote:
The first and perhaps the most obvious, is doing relational queries.
```
where_x_1 = db[x=1]
```
is more beautiful than
```
where_x_1 = db[dict(x=1)]
where_x_1 =
On Mon, Oct 7, 2019, at 10:02, Rhodri James wrote:
> It would still break a lot of user __getitem__ implementations IHMO.
It is already possible to pass any object. The fact that passing an object that
an object is not designed to accept won't get good results doesn't mean the
ability to do so "
> On 7 Oct 2019, at 16:36, Batuhan Taskaya wrote:
>
>
> In fact, that would be a cool feature for ORMs. IMHO instead of ugly call
> chain with filters, slicing is a better option (on `__class_getattr__`). As
> said there are some disadvantages but i think this proposal deserves a PEP.
I re
On 07/10/2019 15:43, Random832 wrote:
On Mon, Oct 7, 2019, at 10:02, Rhodri James wrote:
It would still break a lot of user __getitem__ implementations IHMO.
It is already possible to pass any object. The fact that passing an object that an object
is not designed to accept won't get good resu
On Oct 4, 2019, at 12:34, Caleb Donovick wrote:
>
> Allowing key value pairs in geitem need not change the interface of getitem.
> All the key value pairs could be collected as a dict and passed to getitem
> as the index. Similar to how the all the positional arguments are gather into
> a si
Are you aware of PEP 472 https://www.python.org/dev/peps/pep-0472 ? Maybe
you have something different in mind, but for me your idea looks pretty the
same. While the PEP 472 is in Rejected, Abandoned section, I do not
remember any serious criticism of this idea. It’s just that the authors of
that p
> Are you aware of PEP 472 https://www.python.org/dev/peps/pep-0472 ?
>
That is indeed the same idea, though perhaps the details are a bit
different.
This example from the PEP:
gridValues[x=3, y=5, z=8]
Makes me wonder:
Should that yield the same results as:
gridValues[3,5,8]
Much like posit
> Are you aware of PEP 472 https://www.python.org/dev/peps/pep-0472 ?
Maybe you have something different in mind, but for me your idea looks
pretty the same. While the PEP 472 is in Rejected, Abandoned section, I do
not remember any serious criticism of this idea. It’s just that the authors
of t
On 07Oct2019 10:56, Joao S. O. Bueno wrote:
So, in short, your idea is to allow "=" signs inside `[]` get notation to
be translated
to dicts on the call,
Subjectively that seems like a tiny tiny win. I'm quite -1 on this idea;
language spec bloat to neglible gain.
in the same way comma sep
On 08Oct2019 09:19, Cameron Simpson wrote:
On 07Oct2019 10:56, Joao S. O. Bueno wrote:
So, in short, your idea is to allow "=" signs inside `[]` get notation to
be translated
to dicts on the call,
Subjectively that seems like a tiny tiny win. I'm quite -1 on this
idea; language spec bloat t
On Mon, Oct 7, 2019, at 18:19, Cameron Simpson wrote:
> On 07Oct2019 10:56, Joao S. O. Bueno wrote:
> >So, in short, your idea is to allow "=" signs inside `[]` get notation to
> >be translated
> >to dicts on the call,
>
> Subjectively that seems like a tiny tiny win. I'm quite -1 on this idea;
On 08Oct2019 09:19, Cameron Simpson wrote:
Chris pointed out to me recently that tuples don't need commas,
Cough, "brackets", cough.
the commas alone suffice. You see brackets _around_ tuples a lot
because of precedence.
Reviewing my mail folder, it was actually Steven D'Aprano who pointed
> I think it might be better if it actually passed them as keyword
arguments.
If only keyword arguments are passed what happens to the positional index?
Is it the empty tuple?
Currently subscript with no index (`dict()[]`) is a syntax error should it
continue to be?
> Also, I think there are us
On Mon, 7 Oct 2019 at 19:19, Cameron Simpson wrote:
> On 07Oct2019 10:56, Joao S. O. Bueno wrote:
> >So, in short, your idea is to allow "=" signs inside `[]` get notation to
> >be translated
> >to dicts on the call,
>
> Subjectively that seems like a tiny tiny win. I'm quite -1 on this idea;
>
On Oct 7, 2019, at 14:56, Caleb Donovick wrote:
>
> > I think it might be better if it actually passed them as keyword arguments.
>
> If only keyword arguments are passed what happens to the positional index?
> Is it the empty tuple?
That seems like the obvious, and also most useful, answer.
On 2019-10-07 23:22, Cameron Simpson wrote:
On 08Oct2019 09:19, Cameron Simpson wrote:
On 07Oct2019 10:56, Joao S. O. Bueno wrote:
So, in short, your idea is to allow "=" signs inside `[]` get notation to
be translated
to dicts on the call,
Subjectively that seems like a tiny tiny win. I'm
On Mon, Oct 07, 2019 at 02:22:22PM +0100, Rhodri James wrote:
> On 04/10/2019 20:34, Caleb Donovick wrote:
> >```
> >where_x_1 = db[x=1]
> >```
which would be equivalent to the existing syntax
where_x_1 = db[{'x': 1}]
[Rhodi]
> OK, I'm not sure what you're trying to do here, which all on it
On Tue, Oct 08, 2019 at 09:19:07AM +1100, Cameron Simpson wrote:
> On 07Oct2019 10:56, Joao S. O. Bueno wrote:
> >So, in short, your idea is to allow "=" signs inside `[]` get notation to
> >be translated
> >to dicts on the call,
>
> Subjectively that seems like a tiny tiny win. I'm quite -1 on t
On Mon, Oct 07, 2019 at 05:18:39PM +0200, Anders Hovmöller wrote:
>
>
> > On 7 Oct 2019, at 16:36, Batuhan Taskaya wrote:
> >
> >
> > In fact, that would be a cool feature for ORMs. IMHO instead of ugly call
> > chain with filters, slicing is a better option (on `__class_getattr__`). As
> >
> Why not?
What if I want a getitem that only has keyword arguments? I have to take
the empty tuple as a positional argument, instead of just ensuring that the
key is a dict.
> Now, assuming you want to allow ** in getitem lookups
I don't. *args are not allowed in subscripts either. However, t
It's really not a worthwhile win. It captures a tiny fraction of Pandas
style filtering while complicating the syntax of Python. Here's another
Pandas filter:
db[db.x < 1]
No help there with the next syntax. Here's another:
db[(db.x == 1) | (db.y == 2)]
A much better idea doesn't
On Tue, Oct 8, 2019 at 12:47 PM Caleb Donovick wrote:
>
> > Why not?
>
> What if I want a getitem that only has keyword arguments? I have to take the
> empty tuple as a positional argument, instead of just ensuring that the key
> is a dict.
>
But what if you wanted to take both positional AND
> But what if you wanted to take both positional AND keyword?
I was suggesting that that wouldn't be allowed. So subscript either has a
single argument, a tuple of arguments, or a dictionary of arguments.
Allowing both has some advantages but is less cleanly integratible.
-- Caleb Donovick
On
> It captures a tiny fraction of Pandas style filtering while complicating
the syntax of Python
Sure maybe I we can't represent all filters super concisely but at least
inequalities, or any filter on single axis, would not be hard. E.g.
db[x=LT(1)] == db[db.x < 1]
Granted I don’t really see a w
30 matches
Mail list logo
