simple integer subclass
in [Python]
|
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: rantingrick on 3 Aug 2010 09:06 > On Aug 3, 5:15 am, Andreas Pfrengle <a.pfren...(a)gmail.com> wrote: > > Seems I end up with your suggestion - if noone else has an idea ;-) START_COUNTING_FROM_HERE = 1
From: Jean-Michel Pichavant on 3 Aug 2010 09:41 Andreas Pfrengle wrote: > 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 > -.- > The level of an item is attribute of this item, not an index in a list. You may have an issue with your design, using an improper structure. In a more general manner, given your example I don't see why you should expose the index of an element in an internal list to the user. JM
From: Jean-Michel Pichavant on 3 Aug 2010 09:44 Jean-Michel Pichavant wrote: > Andreas Pfrengle wrote: >> 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 >> -.- >> > The level of an item is attribute of this item, not an index in a list. > You may have an issue with your design, using an improper structure. > > In a more general manner, given your example I don't see why you > should expose the index of an element in an internal list to the user. > > JM > "If there didn't already exist lots of code, I would redesign the whole data-structure" sorry I didn't get this one at first read, my comment is pretty much useless. JM
From: Roald de Vries on 3 Aug 2010 11:43 Hi Andreas, On Aug 3, 2010, at 1:52 AM, Andreas Pfrengle 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? Maybe you could use: 1) a dict with keys 1..n 2) a simple list (or iterable) subclass with 1-based indices. class list1(list): def __new__(cls, *args, **kwargs): return list.__new__(cls, *args, **kwargs) def __getitem__(self, key): return list.__getitem__(self, key-1) ... etcetera Cheers, Roald
From: Stefan Schwarzer on 5 Aug 2010 05:49
Hi Andreas, On 2010-08-03 12:15, Andreas Pfrengle wrote: > On 3 Aug., 03:22, Carl Banks <pavlovevide...(a)gmail.com> wrote:> > 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). Yes, that way your problem may shift from inconvenient to outright hairy. ;-) > 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 What about def _index_to_level(index): return index + 1 with this or a different name? This admittedly is longer than writing `something + 1` but in the latter case you might wonder what the addition is for, i. e. if it's really a level offset calculation or something else. Stefan |