On 2/6/06, Bengt Richter <[EMAIL PROTECTED]> wrote: > Is PEP 237 phase C to be implemented sooner than py3k, > making isinstance(<something>, int) a transparently distinction-hiding alias > for > isinstance(<something>, integer), or outright illegal? IOW, will > isinstance(<something>, int) > be _guaranteed_ to be a bug, thus requiring code change? If so, when?
Probably not before Python 3.0. Until then, int and long will be distinct types for backwards compatibilty reasons. But we want as much code as possible to treat longs the same as ints, hence the party line that (barring attenuating circumstances :-) isinstance(x, int) is a bug if the code doesn't also have a similar case for long. If you find standard library code (in Python *or* C!) that treats int preferentially, please submit a patch or bug. What we should do in 3.0 is not entirely clear to me. It would be nice if there was only a single type (named 'int', of course) with two run-time representations, one similar to the current int and one similar to the current long. But that's not so easy, and somewhat contrary to the philosophy that differences in (C-level) representation are best distinguisghed by looking at the type of an object. The next most likely solution is to make long a subclass of int, or perhaps to make int an abstract base class with two subclasses, short and long. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com