[Python-ideas] Non-boolean return from __contains__
cs at zip.com.au
Wed Jul 28 00:10:48 CEST 2010
On 27Jul2010 16:59, Guido van Rossum <guido at python.org> wrote:
| On Tue, Jul 27, 2010 at 3:29 PM, Mathias Panzenböck
| <grosser.meister.morti at 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. :-(
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.
Cameron Simpson <cs at zip.com.au> DoD#743
"Are we alpinists, or are we tourists" followed by "tourists! tourists!"
- Kobus Barnard <kobus at cs.sfu.ca> in rec.climbing,
on things he's heard firsthand
More information about the Python-ideas