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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4