On Mon, Nov 30, 2009 at 08:40, Wolfgang Schnerring <ws@gocept.com> wrote:
Thus, we should not start requiring zope.component 4.0 everywhere immediately (because it's new, great and shiny ;), but rather use 3.9+future when we want to use the new semantics, and only after I don't know, 6 months maybe, start switching over completely.
Six months? :) The last non-alpha release of Plone is 3.3.2, which runs on Zope 2.10.9, which uses Zope 3.3.2, released over two years ago. If we are to break backwards compatibility we need to make a deprecation warning, and let that run until the large body of Plone code has gotten that deprecation warning and been able to move over to either a "future" syntax or some other syntax before we can actually break the backwards compatibility. So if you multiply those 6 month with 5, then maybe that path forward is feasible. If we want to change the API faster, we need a backwards compatible way, and as mentioned, there doesn't seem to be one. On Mon, Nov 30, 2009 at 14:45, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman <wichert@wiggy.net> wrote:
We could also say that we will clean up the API when we move to Python 3. That is a natural breaking point anyway, so it will not any extra pain for users of the ZCA.
Except that is precisely what the Python developers have asked everyone not to do.
This is true. But the fact is that we don't have any choice. The current 2.x syntax simply doesn't work under Python 3. We *must* change the API, and we will do that by moving implements() to @implementor.
So far the story is that the upgrade to Python 3 can be done largely automatic and a codebase for 2.x and 3.x can be maintained automatically and kept in sync.
And this is still true if you write a fixer for it. So that means we must write a fixer that changes IFoo(bla, bleh) to IFoo(blah, default=bleh). Writing fixers are High Magic, but throw tons of testcases on it and some trial and error works. :) So cleaning up the API for Python 3 is fine, IMNSHO. It will be slightly kludgy to implement it though, but doable. On Mon, Nov 30, 2009 at 16:40, Martin Aspeli <optilude+lists@gmail.com> wrote:
That's a nice theory, but experience suggests it'll be a right mess. Is anyone doing this successfully on a project of a comparable size to Zope? Or Plone? It sounds like fantasy to me. Why? Because if the compatibility really was that "mechanical" there would probably be a way to run Python 2 code in Python 3 - and there isn't.
No, of course nobody has done it with a project of comparable size to Zope and Plone. Is there one even? :-) But that wouldn't be a problem I think. Martin von Löwis has made test-ports of both ZODB and Django to Python 3. The problem is that there are tons of developers involved in the Plone community making a lot of popular and well used third-party components, and getting all of them to support both Python 2 and Python 3 at around the same time (I mean within the same year) seems unlikely, and that risks ending up in a catch 22 situation where nobody moves to Python 3 because nobody else has. But that's a different discussion. Although I have no problems with changing the API for Python 3, both that option and the option of making a slow deprecating means that we can't actually break backwards compatibility for a couple of years anyway. What other options are there? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64