On Sunday 31 March 2002 23:13, Guido van Rossum wrote: ... > > try: thearg+0 > > except TypeError: pass > > else: > > "do the numberlike case here" > > I'm vaguely unhappy with catching exceptions here -- there might be > side effects, and they may mask bugs in user-defined classes that try > to implement __add__ (especially since TypeError is a common symptom > of a bug). Good point, but... if a user-defined class raises TypeError when I try to add 0 to an instance thereof, then I _can't_ use said instance as a number... whether because of a bug in said class, or because said class is not intended to be number-like, I *can't* use it, so I won't. I will then similarly discover I can't use it as a string either, and end up by raising TypeError because by hypothesis I don't know what else to do. This doesn't seem so much of a problem to me to warrant rejecting perfectly good numberlike and stringlike classes' instances, by isinstance'ing away. If a user-defined class is coded to have side effects on __add__, I think any attempt to use instances of that class is doomed to produce weird effects. By that token, the user could subclass int (so isinstance passes) and still do weird things in any overridden method, so I think this is a case of "against stupidity, the god themselves struggle in vain" and would not lose sleep over it. > > Why would you want your function to break if called with an instance > > of UserString, say, or a user-defined number type? Smooth > > polymorphism is high on the list of Python's strong points -- why > > break it, when you can preserve this excellent quality? > > I'm for this; but it's hard to pick the right test in many cases. Oh yes, definitely. > Many types define both __str__ and __int__ -- but either may lose > information (in the case of a float, these *both* lose information!). Every subclass of object has __str__, so having it supplies no information (of any practical usefulness) about the class. __int__ may well lose information -- that's how it's defined, after all -- but having it might be taken as one possible test of numberhood > This leaves me in the uncomfortable position that I don't know what to > recommend. :-( In your shoes, I'd recommend PEP 246 -- since, if I were in your shoes, I'd have approved it long ago. (We don't need to have interfaces as a distinct concept from types/classes to approve PEP 246 -- any types can serve as 'protocols' to make PEP 246 a reality). It would offer a very good solution to problems in this category, in my opinion. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4