[Zope-dev] implementing zope.component 4.0

[Leonardo Rochael Almeida]

I find it rather odd that we're wasting so much time worrying about
backward incompatibility when we have a perfect mechanism to introduce
backward incompatible changes in a way that allows both flavours to be
used by packages in the same application (on a module by module basis
just like Martijn would like):

 * Use a different package name!

Yes, I know, zope.component and zope.interface are such clear and nice
names, and it'd be a shame to let them go for the sake of a new and
better API. But why should we even go down the route of backward
incompatibility? We can keep the backward compatibility forever while
having zero code duplication by implementing the old API on top of the
newer one. It's what we've been doing all these years on zope.app
namespace and even on the Zope 2 codebase. It's a tried and true
method. It's not like we're changing the core Python language in a way
as to correct previous uncorrectable mistakes. It's just a couple of
pakages!

And to have a little bit more of bike sheds to paint, I'll even
suggest the new names:

zc.component and zc.interface. We'll even save a couple of bytes on
every import.

Cheers, Leo

On Mon, Nov 30, 2009 at 10:43, Hanno Schlichting <hanno at hannosch.eu> wrote:
> On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli <optilude+lists at gmail.com> wrote:
>> Martijn Faassen wrote:
>>> This implies we don't want to release zope.component 4.0 for a long time
>>> yet.
>>
>> I think the answer should be "never". :)
>
> I think never is a rather long time. I'd suggest we think about these
> changes more in the timeline of years.
>
> Looking at Python itself or Zope's own former deprecation policies, it
> seems that policies where we deprecate / warn about API changes in one
> release and change behavior it one or two releases after that seem to
> work. They do rely on their being something like a coherent release of
> some language / framework / toolkit though. And they rely on these
> releases being made at an interval of at minimum a year or preferably
> 18 months (as in Python's case).
>
> I think that once we get a ZTK 1.0 release out that promises to be
> maintained for at least three years, we can start working on a ZTK 2.0
> which introduces deprecation warnings about the changed behavior and a
> 3.0 that will change the default. If released at an interval of 18
> months like Python, that puts these changes about 3 years into the
> future with a lot of time in between to adjust.
>
> Given such an approach I think we can indeed change core API's in
> backwards incompatible ways. Python itself does this all the time,
> look at Exceptions as new-style classes, new language keywords like
> "with" or the massive amount of changes in Python 3.
>
> But if we treat zope.component / zope.interface just as two packages
> of their own, I'd agree that we don't have any way to provide
> reasonable backwards compatibility and ensure that some packages won't
> use these straight away. The whole point of the toolkit is to ensure
> we have a large number of packages that are compatible and tested with
> each other.
>
> Hanno
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )
>