[Python-Dev] quick poll: could int, str, tuple etc. become type objects?

[Samuele Pedroni]

Hi.

[GvR]
> > Is the intent of using int and friends as constructors instead of just
> > coercion functions that I should (eventually) be able to do this:
> > 
> >     class NonNegativeInt(int):
> >         def __init__(self, val):
> > 	    if int(val) < 0:
> > 	        raise ValueError, "Value must be >= 0"
> > 	    int.__init__(self, val)
> > 	    self.a = 47
> >         ...
> > 
> > ?
> 
> Yes, sort-of.  The details will be slightly different.  I'm not
> comfortable with letting a user-provided __init__() method change the
> value of self, so I am brooding on a work-around that separates
> allocation and one-time initialization from __init__().  Watch PEP
> 253.

jython already supports vaguely this:

<NonNegInt.py>
from types import IntType as Int

class NonNegInt(Int):
  def __init__(self,val,annot=None):
    if int(val)<0: raise ValueError,"val<0"
    Int.__init__(self,val)
    self._annot = annot

  def neg(self): return -self

  def __add__(self,b):
   if type(b) is NonNegInt: return NonNegInt(Int.__add__(self,b))
   return Int.__add__(self,b)

  def annot(self): return self._annot
</NonNegInt.py>

Jython 2.0 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from NonNegInt import NonNegInt
>>> x=NonNegInt(-2)
Traceback (innermost last):
  File "<console>", line 1, in ?
  File "/home/pedroni/BOX/exp/NonNegInt.py", line 5, in __init__
ValueError: val<0
>>> x=NonNegInt(2)
>>> y=NonNegInt(3,"foo")
>>> y._annot
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: 'int' object has no attribute '_annot'
>>> y.annot()
Traceback (innermost last):
  File "<console>", line 1, in ?
  File "/home/pedroni/BOX/exp/NonNegInt.py", line 15, in annot
AttributeError: 'int' object has no attribute '_annot'
>>> x+y, type(x+y)
(5, <class NonNegInt.NonNegInt at 7958044>)
>>> x.neg()
-2
>>> x+(-2),type(x+(-2))
(0, <jclass org.python.core.PyInteger at 6540407>)
>>> 

As one can see, the semantic is not without holes. The support for this
is mainly a side-effect of the fact that internally jython objects are
instances of java classes and jython allows to subclass java classes.
I have no idea whether someone is already using this kind of stuff, I just
remember that someone reported a bug concerning subclassing ListType so ...

By the way int, long being types seems nice and elegant to me.

A more general note FYI:
I have read the PEP drafts about descrs and type as classes, I have not played
with the descr-branch yet.

I think that the descr and metaclasses stuff can help on jython side
to put a lot of things (dealing with java classes, subclassing from them, etc)
in a more precise framework polishing up many design aspects and the code.

First I suppose that backward compatibility on the jython side is not
a real problem, this aspects are so much under-documented that there are
no promises about them. 

On the other hand until we start coding things on jython side (it's complex
stuff and jython internals are already complex)
it will be really difficult to make constructive comments on possible problems 
for jython, or toward a design that better fits both jython and CPython needs.
Given that we are still working on jython 2.1, maybe we will be able to
start working on jython 2.2 only late in 2.2 release cycle when things are 
somehow fixed and we can only do our best to re-implemnt them.

regards Samuele Pedroni.