On Sun, Mar 23, 2008 at 2:13 PM, Thomas Wouters <thomas at python.org> wrote: > That was always the assumption, and also the idea for 2.6 and 2.7. I would > much rather 3.0 isn't widely accepted for a few years longer than that it be > cluttered with backward compatibility crap, and even rather than that widely > used code be riddled with such. But it's up to Guido in the end. Sure but this is a bit misleading. The risk isn't that 3.0 is not widely accepted quickly. The risk is that the community splits in two. And the suggestion is not for backwards compatibility in 3.0, but forwards compatibility in 2.6. So the question is rather: Do you want to disk a community split, or add forwards compatibility? But as I noted, if it turns out to be necessary to add that forwards compatibility, it's always possible to do a 2.7 that has it. I have loads of experience in writing code for evolving APIs, this is how things have been done in the Zope community for years. It's not a problem. It does not lead to fragile code. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
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