Re: [Python-Dev] quick poll: could int, str, tuple etc. become type objects?
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:
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,
) x.neg() -2 x+(-2),type(x+(-2)) (0, )
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.
participants (1)
-
Samuele Pedroni