On Tuesday 28 October 2003 01:04 am, Greg Ewing wrote: > Alex Martelli <aleaxit at yahoo.com>: > > Nobody's asking for 3.0*x to work where x is a user-coded type > > without an __rmul__; rather, the point is that 3*x should fail too, > > and ideally they'd have the same clear error message as 3+x > > gives when the type has no __radd__. > > Okay, that makes sense. So how do you think we should go about it? I can't see a way right now (at least not for 2.3, i.e. without breaking some programs). A user COULD have coded a class that's meant to represent a sequence AND relied on the (undocumented, I think) feature that giving the class a __mul__ automatically makes instances of that class multipliable by integers on EITHER side, after all. We can't (sensibly), I think, distinguish that from the case where the user has coded a class that's meant to represent a number and gets astonished that __mul__, undocumentedly, makes isntances of that class multipliable by integers on either side. So perhaps for 2.3 we should just apologetically note the anomaly in the docs, and for 2.4 forbid the former case, i.e., require both __mul__ AND __rmul__ to exist if one wants to code sequence classes that can be multiplied by integers on either side...? Any opinions, anybody...? 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