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.
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
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)) 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 mertz@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 steve@pearwood.info wrote: On Tue, Oct 08, 2019 at 09:19:07AM +1100, Cameron Simpson wrote: On 07Oct2019 10:56, Joao S. O. Bueno jsbueno@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-leave@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-leave@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/