On Mon, Mar 24, 2008 at 2:30 AM, Jean-Paul Calderone <exarkun at divmod.com> wrote: > I'm also curious about why Lennart thinks that this would only be relevant > for large projects with lots of developers making regular releases. No, you misunderstood, or I miswrote. I think 2to3 is a procedure that will work well for library type projects with a reasonably small set of developers that make regular releases. There you can release both a python 2 and a python 3 version of the module, for example. I think more future compatibility is relevant for everybody, but I think it's really *necessary* for large projects with lots of developers that do NOT make regular releases, but where releases are done when the project as a whole is done. I.e, the developers themselves work on a project, and use trunk of most modules. Many modules are updated in parallell, and developed on in parallell, and (if the project is reasonably well-managed) releases are made when new releases are sent to the customer. Nuxeo CPS worked like this, but we can ignore them as that project is all but dead will never move to Python 3 in any case. Zope/CMF/Plone works like this. The Plone collective works like this, and it is *not* reasonably well managed, so there software quite often doens't get released, but people run against trunk. I know Django people both strive to support multiple versions of Python and regularily run their production sites on trunk. Insane, perhaps, but that's how things are. :) This is often how big in-house projects work as well, although I don't know of any of those in Python, reasonably because I'm an independent contractor in open source. :) So, in short: Large projects with interconnected modules where the developers and users of module are the same people will have big difficulties with the 2to3 approach and would be the people who are most likely to not be able to in practice go forward to Python 3 unless they have some sort of smooth path forward. -- 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