[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