[Removing python-dev from the CC list] On 5/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > That's why I'd like my alternative proposal (int as ABC and two > > subclasses that may remain anonymous to the Python user); it'll save > > the alignment waste for short ints and will let us use a smaller int > > type for the size for long ints (if we care about the latter). > > I doubt they can remain anonymous. People often dispatch by type > (e.g. pickle, xmlrpclib, ...), and need to put the type into a > dictionary. If the type is anonymous, they will do > > dispatch[type(0)] = marshal_int > dispatch[type(sys.maxint+1)] = marshal_int > > Plus, their current code as > > dispatch[int] = marshal_int > > which will silently break (although it won't be silent if they also > have dispatch[long] = marshal_long).
Fair enough. I'm not sure what the downside of exposing "short" and "long" would be, as long as it remains limited to places where people dispatch on type(x) -- isinstance(x, int) should always work. And, as /F notes, hopefully some overloading/dispatching/generic functions machinery would help. If we really want all ints to have the same type, a hackish proposal would be to tweak type() and the __class__ attribute to lie, returning the 'int' type object when the type or class of a short or long is requested. This should probably go with a prohibition on subclassing int to avoid confusion. At the C level, the concrete types would be exposed. -- --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
