On 27Jul2010 16:59, Guido van Rossum email@example.com wrote: | On Tue, Jul 27, 2010 at 3:29 PM, Mathias Panzenböck | firstname.lastname@example.org 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. :-(
That's a real shame.
For the record (since I just said +0.5 to +1), I'm down to +0 on the proposal; I think the idea's good and removes an (to my mind) arbitrary constraint on __contains__, but now I haven't got a use case:-(
Alex's "id in wrapper([1,2,3])" doesn't seem better than the existing "column.in_([1,2,3])" that already exists, alas.