Guido van Rossum wrote: > On 9/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >> What impact is this long/int unification going to have on C-based >> sub-types of the old int-type? Will you be able to sub-class the >> integer-type in C without carrying around all the extra backage of the >> Python long? > > > This seems unlikely given that the PyInt *type* will go away (though > the PyInt *API* methods may well continue to exist). You can subclass > the PyLong type just as easily. What baggage are you thinking of?
Just the extra stuff in the C-structure needed to handle the arbitrary-length integer. > > If you're thinking of the current special-casing for e.g. list[int] in > ceval.c, that code will likely disappear (although something > equivalent will eventually be added). Yes, that's what I'm thinking of. It would be nice if the "something equivalent" could be extended to other objects. I suppose the discussion can be held off until then. > > But now that we have __index__, of course, there's less reason to > subclass PyInt in the first place -- you can write your own 32-bit > integer *without* inheriting from PyInt or PyLong, and it should be > usable perfectly whenever an integer is expected. Id rather make sure > *this* property is provided without compromise than attempting to keep > random older optimizations alive for nostalgia's sake. Of course, I agree entirely, so I doubt it will matter at all (except in optimizations). There is probably going to be an increasing need to tell whether or not something can handle one of these interfaces. I know this was already discussed on this list, but was a decision reached about how to tell if something exposes a specific interface? (I think the relevant discussion took place under the name "callable"). I see a lot of isinstance(obj, int) in scientific Python code where testing for __index__ would be more appropriate. Thanks for easing my mind. -Travis _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
