On Tue, Jul 27, 2010 at 9:02 AM, Alex Gaynor email@example.com wrote:
On Tue, Jul 27, 2010 at 10:59 AM, Guido van Rossum firstname.lastname@example.org wrote:
On Tue, Jul 27, 2010 at 3:29 PM, Mathias Panzenböck email@example.com wrote:
On 07/26/2010 04:20 AM, Alex Gaynor wrote:
Fundamentally the argument in favor of it is the same as for the other comparison operators: you want to do symbolic manipulation using the "normal" syntax, as a DSL. My example is that of a SQL expression builder: SQLAlchemy uses User.id == 3 to create a clause where the ID is 3, but for "id in [1, 2, 3]" it has: User.id.in_([1, 2, 3]), which is rather unseamly IMO (at least as much as having User.id.eq(3) would be).
This is a bad example for your wish because this code:
id in [1, 2, 3]
[1, 2, 3].__contains__(id)
So it doesn't help that 'in' may return something else than a bool because the method is called on the wrong object for your purposes.
Well that pretty much kills the proposal. I can't believe nobody (including myself) figured this out earlier in the thread. :-(
-- --Guido van Rossum (python.org/~guido)
Well, in my original example I wrapped the list with a SQLList() container class. I thought of the issue before, but it hardly seems like a blocker, the numpy stuff is unaffected for example: they're not using a builtin container, and for myself I'm willing to wrap my lists to get the pretty syntax.
Well, writing "x in wrapper(y)" is hardly prettier than "contains(y, x)", if you compare it to "x in y".
And it is certainly another thing that can go wrong in a non-obvious way.