Guido van Rossum wrote: > On 9/4/07, Robert Kern <robert.kern at gmail.com> wrote: >> The 3.x compatibility break (however alleviated by 2to3) makes a nice clean >> cutoff. The numpy that works on Pythons 3.x would essentially be a port from the >> current numpy. Consequently, we could modify the numpy for Pythons 3.x to always >> rely on the stdlib API to build on top of. We couldn't do that for the version >> targeted to Pythons 2.x because we could only rely on its presence for 2.6+. I >> don't mind maintaining two versions of numpy, one for Python 2.x and one for >> 3.x, but I don't care to maintain three. > > I just had a discussion with Glyph "Twisted" Lefkowitz about this. He > warns that if every project using Python uses 3.0's incompatibility as > an excuse to make their own library/package/project incompatible as > well, we will end up with total pandemonium (my paraphrase). I think > he has a good point -- we shouldn't be injecting any more instability > into the world than absolutely necessary. I agree. I didn't mean to imply that the 3.x version of numpy would be incompatible to users of it, just that the codebase that implements it will be different, whether it is automatically or manually translated. Of course, if the API is introduced in 3.(x>0), we end up with the same problem I wanted to avoid. Ah well. See you on the flip side of the PEP. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
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