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