[Python-ideas] Non-boolean return from __contains__

Michael Foord fuzzyman at voidspace.org.uk
Sun Jul 25 23:32:59 CEST 2010


On 25 July 2010 19:48, Raymond Hettinger <raymond.hettinger at gmail.com>wrote:

>
> On Jul 25, 2010, at 11:15 AM, Alex Gaynor wrote:
>
> > Recently I've been wondering why __contains__ casts all of it's
> > returns to be boolean values.  Specifically I'd like to propose that
> > __contains__'s return values be passed directly back as the result of
> > the `in` operation.
>
> x = y in z          # where x is a non boolean.
>
> Yuck.
>
>

How is it any worse than:


 x = y > z # where x is a non boolean

And all the other operators that already do this?

Michael



> One of the beautiful aspects of __contains__ is that its simply signature
> allows it to be used polymorphically throughout the whole language.
> It would be ashamed to throw-away this virtue so that you can
> have a operator version of something that should really be a method
> (like find() for example).
>
> -1 on the proposal because it makes the language harder to grok
> while conferring only a dubious benefit (replacing well named
> methods with a non-descriptive use of an operator).
>
> There is no "natural" interpretation of an in-operator returning
> a non-boolean.  If the above snippet assigns "foo" to x, what
> does that mean?  If it assigns -10, what does that mean?
> Language design is about associating meanings (semantics)
> with syntax.  ISTM, this would be poor design.
>
>
> Raymond
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
http://www.voidspace.org.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100725/41f4ea6e/attachment.html>


More information about the Python-ideas mailing list