Jim Fulton wrote:
IMO, the Python standard library and "batteries included" is a mess.
Despite being a Python contributor, I've very unmotivated to be a
contributor because the time lag between contributing and deriving
benefit from the contributions is too long. People had similar
complaints about Zope releases. I'll note that the problem is
exacerbated by the incompatibilities that (to some degree inevitably)
often occur in Python releases. Big-bang releases don't prevent update
While I see Brandon making good points, I also agree with this: the
motivation to contribute to the Python standard library is reduced
because of big bang releases. I think the main reason is that you need
to wait so long to see your work "in print" so you can use it yourself.
(the other one is particular to Python core developer culture, who I
believe are more interested in language tweaks than library improvements).
Instead if I just release my own library I can release and use it
immediately (and get others to use it). I've seen the same with Zope 3
releases in the past. I think a predictable, regular release cycle can
help there, even though that has its own problems.
Splitting Zope up into independently evolving parts can help too. It
also has its own problems, some of which Brandon just pointed out. I've
also see the benefit of this already: Philipp can work on WSGI support
in zope.app.publisher or whatever and get it released so that, say,
Grok, could start using it, without having to wait for a major Zope 3
release, which we've historically not been very good at producing
It also means that one or more other projects will need to take over the
task of producing "big bang" releases out of a collection of these
smaller releases. This could be the index we've been speaking about, or
Zope 2, or Grok, or all of them combined. I will agree that Zope 3 is
somewhat special in that it tends to be more of an ecosystem than a
piece of software.
Zope3-dev mailing list