Label-Value (was: Re: Inheriting the @ sign from Ruby)

[Rainer Deyke]

"Quinn Dunkan" <quinn at dinar.ugcs.caltech.edu> wrote in message
news:slrn93o7j4.tu0.quinn at dinar.ugcs.caltech.edu...
> 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.

__coerce__ would probably have been superior, since it eliminates duplicate
code and more closely resembles the way real integers work in Python.


--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor