[Python-Dev] Int FutureWarnings and other 2.4 TODOs
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
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
More information about the Python-Dev