Label-Value (was: Re: Inheriting the @ sign from Ruby)
Quinn Dunkan
quinn at dinar.ugcs.caltech.edu
Sat Dec 16 21:06:55 EST 2000
On Fri, 15 Dec 2000 16:38:47 GMT, Rainer Deyke <root at rainerdeyke.com> wrote:
>Yes, in-place modification should be supported. I had something like this
>in mind:
>
>class UserInt:
> def __init__(self, value):
> self.data = value
> def __add__(self, other):
> if isinstance(other, UserInt):
> return self.__class__(self.data + other.data)
> else:
> return self.__class__(self.data + other)
> __radd__ = __add__
> def __iadd__(self, other):
> if isinstance(other, UserInt):
> self.data += other.data
> else:
> self.data += other
> # Repeat for all other operations
>
>UserInt as written is more properly UserNumber, since it supports longs ints
>and floats.
Just as a matter of style, would it be superior to add a __coerce__ method
that knows how to coerce ints, longs, and floats into UserInts, or make an
explicit check on each method? __coerce__ saves a lot of typing, but I'm
generally wary of implicit things like coercion. When I implemented a class
like this (a vector, actually), I used __coerce__, but after trying to wrap my
brain around the control flow, I was thinking maybe I wouldn't next time, even
though it seems to work fine.
Is this fear unfounded? Is there a better way?
More information about the Python-list
mailing list