> 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. > That type object would be smart enough to realize that any time the > object it is dealing with had a value in the range [-MAXINT-1, > MAXINT] that it was ACTUALLY using the layout now known as "int". This part doesn't make sense -- the value cannot be known unless the layout is known. But it shouldn't matter -- the long methods should never be passed a short representation, because at the C level the short implementation would be invoked automatically through the vtable or type. Of course, the long code should be careful to downcase any *results* in the short range to the short representation before returning it. > This would require some clever tricks in the implementation of the > "long" type object, but that's not where we care about performance. > Of course, it's possible that there are no tricks clever enough to > handle this -- I certainly don't know how to do it, but I wouldn't > be TOO surprised if someone else here did. Someone ought to try to implement this on a branch or as a patch, to see how feasible it is. --Guido van Rossum (home page: http://www.python.org/~guido/)
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