[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Jack Jansen]

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