[Python-ideas] Non-boolean return from contains (original) (raw)
Raymond Hettinger raymond.hettinger at gmail.com
Mon Jul 26 02:01:11 CEST 2010
- Previous message: [Python-ideas] Non-boolean return from __contains__
- Next message: [Python-ideas] Non-boolean return from __contains__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jul 25, 2010, at 2:32 PM, Michael Foord wrote:
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?
Terrible sales technique: "how is this any worse than ..." ;-)
Other operations such as rich comparisons have complicated our lives but had sufficient offsetting benefits than made them more bearable. Rich comparisons cause no end of trouble but at least they allow the numeric folks to implement some well studied behaviors than have proven benefits in their domain.
In contrast, this proposal offers almost zero benefit to offset the pain it will cause. The OP didn't even offer a compelling use case or a single piece of code that wouldn't be better written with a normal method.
No existing code expects "in" to return a non-boolean. A lot of code for containers or that uses containers implicitly expects simple invariants to hold:
for x in container: assert x in container
Raymond
P.S. With rich comparisons, we've lost basics assumptions like equality operations being reflexsive, symmetric, and transitive. We should be cautioned by that experience and only go down that path again if there is a darned good reason. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100725/b802b3c9/attachment.html>
- Previous message: [Python-ideas] Non-boolean return from __contains__
- Next message: [Python-ideas] Non-boolean return from __contains__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]