[Python-Dev] Int FutureWarnings and other 2.4 TODOs (original) (raw)

Jack Jansen Jack.Jansen at cwi.nl
Fri Dec 5 05:13:35 EST 2003

On 5-dec-03, at 2:52, Edward Loper wrote:

If you agree with this premise, then it suggests a different approach. Use different implementations in C, but have type(x) in Python lie. type(x) would always return the type object which is now known as "long". If this can be made to work, I like it. class should also be hacked, and isinstance(); and who knows how many other places, but probably not too many. If we go this route, then how general should the mechanism for "merging" types in Python-space (but keeping them separate in c-space) be? I.e., should this be an integer-specific change, or a general mechanism that happens to be used by int? It seems like there might be other use cases for similar "merges" (string/unicode comes to mind).

I think this is a good idea, I may have some uses for it too. But, more importantly, making this a general mechanism will force us to formulate the exact set of restrictions we place on two such types.

Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

More information about the Python-Dev mailing list