Label-Value (was: Re: Inheriting the @ sign from Ruby)
Quinn Dunkan
quinn at dinar.ugcs.caltech.edu
Sat Dec 16 21:14:21 EST 2000
More information about the Python-list mailing list
Sat Dec 16 21:14:21 EST 2000
- Previous message (by thread): Label-Value (was: Re: Inheriting the @ sign from Ruby)
- Next message (by thread): Label-Value (was: Re: Inheriting the @ sign from Ruby)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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?
- Previous message (by thread): Label-Value (was: Re: Inheriting the @ sign from Ruby)
- Next message (by thread): Label-Value (was: Re: Inheriting the @ sign from Ruby)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list