[Zope-dev] implementing zope.component 4.0

[Martijn Faassen]

Martin Aspeli wrote:
> Martijn Faassen wrote:
[snip]
>> That's why I think it's important to have a:
>>
>> * a zope.component 3.x that supports both patterns
>>
>> * a per-module way to indicate whether the new API should be used.
> 
> Sorry, I just don't buy it. The *moment* someone requires >= 4.0, you're 
> screwed.

See discussion below.

> And per-module flags are ugly and confusing. I'm quite sure most people 
> never import from __future__ in Python, just because it's so hard to see 
> what's going on and so annoying to have to remember to do it.

 From future imports are going to be part of our life for a significant 
period, as we go through Python 2.6 and then presumably, sometime, to 
Python 3.x.

>> We'd commit to maintaining zope.component 3.x in parallel with 
>> zope.component 4.0. We'd recommend to people *not* to require 
>> zope.component 4.0 for a period, or perhaps we'd even not release it for 
>> quite a period.
> 
> This sounds like we're making excuses for making a bad choice. What's 
> the point of releasing a package if we encourage people not to use it? 
> Or not to use it "yet"? When does "yet" end?
> 
> We won't be able to control what people do in their code. And it only 
> takes one package to depend on 4.0 for it to all go wrong for anyone 
> using the current, documented, *encouraged* pattern.

So I'm adjusting my story to say we shouldn't release zope.component 4.0 
at all. We should first go through zope.component 3.x which gives:

* a deprecation error if 'default' is not used explicitly.

* a from future mode so that the new semantics can be used on a 
per-module basis.

[snip documentation issue being severe, if not criminal]

>>>> I think it's important not to do a "big bang" upgrade but instead allow 
>>>> people to upgrade bit by bit. It should be possible to compose an 
>>>> application that mixes code that expects the old semantics with code 
>>>> that expects the new semantics. A bit by bit upgrade I think would 
>>>> ideally be on a per-module basis. I think it's important to make sure we 
>>>> can support such an upgrade *before* we release any of this.
>>> I'm not sure that's going to be possible. As soon as someone does 
>>> zope.component >= 4.0 in their setup.py, you're screwed.
>> This implies we don't want to release zope.component 4.0 for a long time 
>> yet.
> 
> I think the answer should be "never". :)
> 
> To put this into perspective: we're going to cause a lot of pain for a 
> lot of people for something that is *purely* cosmetic. We're indulging 
> in a whim for "perfect" API design at the expense of people who signed 
> up to our old API.
> 
> Sometimes, we need to accept that our past decisions are with us to 
> stay. I think that's a sign of maturity and attention to our customers, 
> rather than weakness.

Tell that to the Python core developers. :)

Anyway, I'm a bit more flexible on the issue of backwards compatibility. 
But the deeper in the stack we are the more careful we should be, 
indeed, as there are many consumers, directly and indirectly.

> There are solutions in these threads which are backwards compatible, or 
> at least backwards compatible in the vast majority of cases. They may 
> not be exactly as pretty, but in my book they are infinitely preferable.
> 
> I would much, much rather have none of these improvements and not break 
> all that code. What we have now works. We would just like it to be a 
> little bit prettier and a bit more obvious. Those are laudable goals, 
> but not at any expense.

The most elegant backwards compatible solution would be multi adaptation 
using a tuple. I think 'name' can probably also be added to the adapter 
hook without breaking stuff. People adapting tuples will need an 
explicit way to do so. It's still backwards incompatible, but the impact 
is less big.

In any case, I would like to deprecate non-explicit keywords parameters 
for 'default' and 'name'.

Regards,

Martijn