Extention to the integer class.

[Steve Holden]

Gregoire Welraeds wrote:
> 
> Hello pythoniens!
> 
> I got a question for you...
> 
> I want to extend the integer class to add two stupid methods :
> i.i(x)  # inc i with x or with 1 if x is not present
> i.d(x)  # dec i of x or of 1 if x is not present
> 
When you say "extend the integer class", do you mean "extend the
Python built-in integer type"?  As you may know, these aren't quite
the same kind of objects as those classes you define yourself.

> So I have done the following class :
> class Int:
>         def __init__(self,value):
>                 self.__val= value
>         def __cmp__(self, value):
>                 if self.__val < value:
>                         return -1
>                 elif self.__val == value:
>                         return 0
>                 else: return 1
>         def i(self, value= 1):
>                 self.__val= self.__val + value
>                 return self.__val
>         def d(self, value= 1):
>                 self.__val= self.__val - value
>                 return self.__val
> 
> Now this work with :
> i = i+a         => i.i(a)
> i = i-a         => i.d(a)
> i++             => i.i()
> i--             => i.d()

... where i is an Int and a is an integer ...

> Thanks to the __cmp__() methods, it also work with :
> i < a
> i >= a
> i <= a
> i > a
> ...
> 
... where i is an Int and a is an integer ...

> But It fails when i use i as an index in a list ex: list[i]

Presumably with "TypeError: sequence index must be integer"

This is because the sequence types (strings, lists and tuples)
do not know what to do with an Int as a subscript.  And, like
the integers, the basic sequence types are built-in and hence
not quite first-class objects.

The implementation crew seem to have spent a lot of time
discussing the implications of this differentiation between
built-in types and programmer-defined objects, because
the distinction leads to the kinds of nastinaess you have run
into.  I'm not up to speed on any planned changes, however.

> I could create a get method :
>         def get(self):
>                 return self.__val
> but it is very poor since each time i is a index, i have to write i.get().
> ex: list[i.get]
> 
Yes, list[i.get()] is indeed a poor substitute for list[i] ...

> So my question is double :
>         can I extend the Integer class to add inc and dec ?
>         Is there a way to write i and have the interpreter understand
>         i.get() or something similar (as it may do with plain integer) ?
> 

It would appear that the sequence object access methods do not allow
automatic coercions to integer.  In other words

	(1,2,3)["1"]

will also give a TypeError, even though it "seems obvious" that the
string should be coerced to an integer and used as a subscript.

I can think of nothing that might persuade Python to run an object
method when only its name is given.  The name of an object instance
more or less has ro be usable to refer to the whole object -- how,
otherwise, could you have

	i.d()

extract the d() method from the object i?  So you might have to
accept a little disappointment here...

However, if you look in Section 3 of the Python library reference
you will find UserList, which is a wrappered version of the built-in
list type.  If you inspect the code you may be able to do what you
want by extending UserList so when the __getitem__ method is called
with an Int it extracts the Int's __val attribute and uses that.

> I understand that the interest of the goal is somewhat limited... but
> thanks :))
> 

comp.lang.python is one of the few places where the readership's
taste is still reliably catholic (note the lack of capitalisation).
There's even a current thread on Forth interpreter implementation
strategies, so I hardly think you're way off base here: at least
you are discussing Python!

> --
> Life is not fair
> But the root password helps
> --

"Life?  Don't talk to me about life.  I'[ve got this pain in all
the diodes down my left side."  Marvin the paranoid android, in
"The Hitchhiker's Guide to the Galaxy".

> 
> Gregoire Welraeds
> greg at perceval.be
> Perceval Development team
> -------------------------------------------------------------------------------
> Perceval Technologies sa/nv     Tel: +32-2-6409194
> Rue Tenbosch, 9                 Fax: +32-2-6403154
> B-1000 Brussels                 general information:   info at perceval.net
> BELGIUM                         technical information: helpdesk at perceval.net
> URL: http://www.perceval.be/
> -------------------------------------------------------------------------------

regards
 Steve
--
"If computing ever stops being fun, I'll stop doing it"