[Python-Dev] the "3*x works w/o __rmul__" bug
Alex Martelli
aleaxit at yahoo.com
Mon Oct 27 03:06:44 EST 2003
More information about the Python-Dev mailing list
Mon Oct 27 03:06:44 EST 2003
- Previous message: [Python-Dev] Re: [Python-checkins] python/dist/src/Python bltinmodule.c, 2.292.10.1, 2.292.10.2
- Next message: [Python-Dev] Re: the "3*x works w/o __rmul__" bug
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Monday 27 October 2003 04:22, Greg Ewing wrote: > Alex Martelli <aleaxit at yahoo.com>: > > Exactly the same underlying reason as a bug I just opened on > > SF: if x is an instance of a class X having __mul__ but not > > __rmul__, 3*x works (just like x*3) but 3.0*x raises TypeError > > Seems to me the bug there is not giving X an __rmul__ > method and yet expecting y*x to work at all. The fact > that it happens to work in some cases is an accident > that should not be relied upon. No, the bug is that it works in some cases where it should fail (and, secondarily, that -- where it does fail -- it gives a weird error message). In other words, the bug (in Python) is that "accident". 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__. Doesn't seem trivial to fix (though I hope I'm missing something obvious) and doesn't affect perfect user-programs, but I do think it should be fixed because it's sure extremely mysterious and could send a developer on wild goose chases when met in the course of development. Alex
- Previous message: [Python-Dev] Re: [Python-checkins] python/dist/src/Python bltinmodule.c, 2.292.10.1, 2.292.10.2
- Next message: [Python-Dev] Re: the "3*x works w/o __rmul__" bug
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list