On Tue, Jul 27, 2010 at 10:59 AM, Guido van Rossum guido@python.org wrote:
On Tue, Jul 27, 2010 at 3:29 PM, Mathias Panzenböck grosser.meister.morti@gmx.net 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]
translates into:
[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.
Alex