On 9/5/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > 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.
That's just an int length and 15-for-16-bits encoding of the actual value. > > 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. I wouldn't rip this out just yet. 'int' may become an abstract type yet -- the int/long unification branch isn't the final word (if only because it doesn't pass all the unit tests yet). > Thanks for easing my mind. You're welcome. And how's that PEP coming? :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
