[Zope-dev] implementing zope.component 4.0

[Lennart Regebro]

On Mon, Nov 30, 2009 at 08:40, Wolfgang Schnerring <ws at 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 at hannosch.eu> wrote:
> On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman <wichert at 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 at 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