Prev: Package management (was: Why is there no platform independent way of clearing a terminal?)
Next: calling a class method from a menu in a different class
From: Andreas Pfrengle on 2 Aug 2010 19:52 I'm trying to define a subclass of int called int1. An int1-object shall behave exactly like an int-object, with the only difference that the displayed value shall be value + 1 (it will be used to display array indices starting at 1 instead of 0). Right now I have: class int1(int): def __str__(self): return int.__str__(self + 1) However, if I calculate with int1 and int- (or other number) objects, the result is always coerced to an int (or other number object), e.g: a = int1(5) b = 5 print a # "6" print a+b #"10" How can I tell int1 to be the "default integer object"? Do I need to overload *every* mathematical operation method of int, or is there an easier way?
From: samwyse on 2 Aug 2010 20:24 On Aug 2, 6:52 pm, Andreas Pfrengle <a.pfren...(a)gmail.com> wrote: > I'm trying to define a subclass of int called int1. An int1-object > shall behave exactly like an int-object, with the only difference that > the displayed value shall be value + 1 (it will be used to display > array indices starting at 1 instead of 0). Right now I have: > > class int1(int): > def __str__(self): > return int.__str__(self + 1) > > However, if I calculate with int1 and int- (or other number) objects, > the result is always coerced to an int (or other number object), e.g: > a = int1(5) > b = 5 > print a # "6" > print a+b #"10" > > How can I tell int1 to be the "default integer object"? Do I need to > overload *every* mathematical operation method of int, or is there an > easier way? I had a similar problem a few years ago, and couldn't find a solution then. The thread from back then may shed some light on your problem. http://groups.google.com/group/comp.lang.python/browse_thread/thread/10cfe2affc265ac/2ad03b121c1c6489
From: Carl Banks on 2 Aug 2010 21:22 On Aug 2, 4:52 pm, Andreas Pfrengle <a.pfren...(a)gmail.com> wrote: > I'm trying to define a subclass of int called int1. An int1-object > shall behave exactly like an int-object, with the only difference that > the displayed value shall be value + 1 (it will be used to display > array indices starting at 1 instead of 0). Right now I have: > > class int1(int): > def __str__(self): > return int.__str__(self + 1) > > However, if I calculate with int1 and int- (or other number) objects, > the result is always coerced to an int (or other number object), e.g: > a = int1(5) > b = 5 > print a # "6" > print a+b #"10" > > How can I tell int1 to be the "default integer object"? Do I need to > overload *every* mathematical operation method of int, or is there an > easier way? (Preface: I normally don't offer recommendations without answering the question as asked, but once in a while it has to be done.) I **highly** recommend against this approach. You are creating an object that differs from a built-in, int, in a highly misleading way that only makes sense in a very limited context, and this object's modified behavior gives no clue that it's been modified in such as way. (That is, it's not possible to tell if the object's not a regular int just by looking at __str__()'s return value.) To make matters worse, you want to program this object to coerce other integers, so there's a risk of these objects escaping from the context where they make sense. This is just a bad idea. The type is not the place to implement behavior that makes sense only in a limited context. Instead, do something like this: print "Item %d is %s." % (i+1, s[i]) Carl Banks
From: rantingrick on 2 Aug 2010 23:36 On Aug 2, 6:52 pm, Andreas Pfrengle <a.pfren...(a)gmail.com> wrote: > I'm trying to define a subclass of int called int1. An int1-object > shall behave exactly like an int-object, with the only difference that > the displayed value shall be value + 1 (it will be used to display > array indices starting at 1 instead of 0) Is zero based indexing that bad for you? I also think this is a very bad idea unless you can offer a sensible use case -- for which i cannot imagine.
From: Andreas Pfrengle on 3 Aug 2010 06:15
On 3 Aug., 03:22, Carl Banks <pavlovevide...(a)gmail.com> wrote:> > You are creating an object that differs from a built-in, int, in a > highly misleading way that only makes sense in a very limited context, > and this object's modified behavior gives no clue that it's been > modified in such as way. (That is, it's not possible to tell if the > object's not a regular int just by looking at __str__()'s return > value.) To make matters worse, you want to program this object to > coerce other integers, so there's a risk of these objects escaping > from the context where they make sense. > > This is just a bad idea. The type is not the place to implement > behavior that makes sense only in a limited context. Instead, do > something like this: > > print "Item %d is %s." % (i+1, s[i]) I see your concerns. I started with the approach to add +1 directly before displaying the int. However, since there are some variables that shall be displayed normally and others that are indices I want to show starting at 1, I thought the easiest way would be to define a type that does the job, then I would only need to define it once and not take care everywhere whether I have a normal variable or a displayed index. Thinking about it, it might really be dangerous to coerce always to int1, since sometimes I might want a normal int as result (I can't tell yet for sure). I'm just thinking about only overloading the operations if the int1 is on the left-hand side (so __op__ coerces to int1, while __rop__ doesn't). This would make operations non-commutative - but I also would need to put more brains in every calculation, which could finally take more effort than only "upgrading" the display :-??? Seems I end up with your suggestion - if noone else has an idea ;-) The application will be a browsergame, and most gamers start counting at 1, so they would probably wonder about a "level 0 item" ;-) If there didn't already exist lots of code, I would redesign the whole data-structure - I think that's "lessons learned" for the next project -.- |