simple integer subclass

[Jean-Michel Pichavant]

Andreas Pfrengle wrote:
> On 3 Aug., 03:22, Carl Banks <pavlovevide... at 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