Raymond Hettinger wrote: >> Giovanni Bajo wrote: >>> Another workaround could be: > > Before focusing mental talents on workarounds and implementations, > it would be worthwhile to consider whether the idea would help or > hurt the language. The and/or keywords already have some complexity > due to their returning non-boolean values. IMO, it would be a disservice > to the language to further complexify their meanings. Right now, at least, > we can make a static reading of the code and have a good idea of what > the and/or keywords mean.
It would probably hurt the language, and for the record, I'm against it. We already have problems with rich comparisons not reliably returning booleans. It's a fairly common occurrence to do equality testing against generic data types. For example, finding if an object is in a list with list.index(). However, this does not reliably work when == can return something that is not interpretable as a boolean value like numpy arrays do. I don't think rich comparisons are a mistake (I use them much more frequently than I use list.index(), for example), but propagating the uncertainty further is probably a mistake. For numpy, the bitwise operators |&~ work fine on boolean arrays, and that's all such operators really need to work on. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
