Caleb Donovick wrote:
> > 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]

Django for example allows filtering with keyword args including inequalities in 
this way: `x__lt=1` (which translates to "x < 1"). Whether that's more readable 
or not is another question but at least with "keyword args" in `[]` every 
package could come up with its own specifications on how this is used.

> Granted I don’t really see a way to express logical connectives between
> filters in a beautiful way -- beyond doing something like db[filter=OR(x=1,
> y=2)] which really isn't any better than db.filter(OR(x=1, y=2))
> > db['x=1']
> > Ah yes cause parsing strings is a reasonable replacement for language
> support.  I have no idea why Pandas dropped support for this but I have to
> imagine it's because it's horribly ugly, prone to bugs and difficult to
> metaprogram.

Pandas didn't drop the support for query strings, they can be used via the 
`df.query` method. For example: `df.query('x == 1 and y == 2')`. That's equally 
explicit but creating query strings (dynamically) has of course its downsides. 
Given that `[]` is used for element access, extending it to further use cases 
is indeed appealing.

On the other hand one could always argue that a functional interface equally 
does the job, e.g. pandas could provide a function accepting keyword args: 
`df.select(x=1, y=2)`. Or the Django style: `Q(x=1) | Q(y__lt=2)`.

Semantically meaningful strings are terrible. Everytime I
> write a string literal for any reason other than I a want human to read
> that string I die a little inside.  Which is part of the reason I want
> db[x=1] instead of db[{'x':1}].  And yes everything is a string under the
> hood in python but that doesn't make semantic strings less terrible. Really
> under the hood (in assembly) everything is gotos but that doesn't make
> their use better either. /rant
> On Mon, Oct 7, 2019 at 10:07 PM David Mertz me...@gnosis.cx
> wrote:
> > 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 require any changes in Python, just a clever
> > class method. Pandas did this for a while, but deprecated it because...
> > reasons. Still, the OP is free to create his version:
> > db['x=1']
> > 
> > Or
> > db['x<1']
> > db['x=1 or y=2']
> > 
> > You can bikeshed the spelling of those predicates, but it doesn't matter,
> > they are just strings that you can see however you decide is best.
> > On Mon, Oct 7, 2019, 8:38 PM Steven D'Aprano st...@pearwood.info wrote:
> > On Tue, Oct 08, 2019 at 09:19:07AM +1100,
> > Cameron Simpson wrote:
> > On 07Oct2019 10:56, Joao S. O. Bueno jsbu...@python.org.br 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.
> > As per Caleb's initial post, this is how Pandas currently does it:
> > db[db['x'] == 1]
> > 
> > Replacing that with db[x=1] seems like a HUGE win to me.
> > Even db[{'x': 1}] is pretty clunky.
> > --
> > Steven
> > 
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-ideas@python.org/message/RQH4VJ...
> > Code of Conduct: http://python.org/psf/codeofconduct/
> > 
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-ideas@python.org/message/5O7BLO...
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3LXDQE7ICKIE2KIZWJORFBRAL5M3NHLT/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to