On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro <regebro at gmail.com> wrote: > On Tue, Mar 15, 2011 at 15:39, "Martin v. Löwis" <martin at v.loewis.de> wrote: >> Of course you could have. You could have added a version of your code >> that uses capsules (just as you are probably doing now). > > No I'm not. The numpy folks have shown it is quite possible to support 3.2 without sacrificing compatibility with earlier versions. >> Right - and that's why the deprecation period is not about supporting >> multiple versions, but to reduce the need for people to adjust their >> code on a quick notice. > > I think we need to adjust PEP 5 then. We can't keep on breaking > backwards compatibility like this. People are already freaked out > about Python 2 to Python 3, and the argument is often used against > Python that it's not a language to be used in enterprise situations > because Python keeps on breaking backwards compatibility. Up until 3.2 > that statement was not actually true. Python 2.x was very backwards > compatible. The next time somebody tells me that Python isn't stable > and breaks backwards compatibility all the time, and says that's why > you should use Java, what can I now say? OK, it's just the C-API, but > that excuse isn't going to fly... But given that this situation was unique to the parallel development of 2.x and 3.x, and PEP 5 was applied correctly within each of the parallel lines of development, why not just consider this another instance of the 2.x/3.x incompatibility? That's what it is after all. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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