[Aahz]
At the same time, I think each individual
change that doesn't clearly fall into the PEP6 process of being a bugfix
needs to be vetted beyond what's permitted for not-yet-released versions.
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after feature freeze), the bsddb code was
ripped out (good riddance). This had the unfortunate side-effect of
crippling shelves which now fall back to using dumbdbm.
I'm somewhat working on an alternate dbm based on sqlite3:
http://code.activestate.com/recipes/576638/
It is a pure python module and probably will not be used directly, but shelves
will see an immediate benefit (especially for large shelves) in terms of speed
and space.
On the one hand, it is an API change or new feature because people can
(if they choose) access the dbm directly. OTOH, it is basically a performance
fix for shelves whose API won't change at all. The part that is visible and
incompatible is that 3.0.1 shelves won't be readable by 3.0.0.
The problem is that the obvious candidate for doing the vetting is the
Release Manager, and Barry doesn't like this approach. The vetting does
need to be handled by a core committer IMO -- MAL, are you volunteering?
Anyone else?
It should be someone who is using 3.0 regularly (ideally someone who
is working on fixing it). IMO, people who aren't exercising it don't really
have a feel for the problems or the cost/benefits of the fixes.
Barry, are you actively opposed to marking 3.0.x as experimental, or do
you just dislike it? (I.e. are you -1 or -0?)
My preference is to *not* mark it as experimental. Instead, I prefer
doing what it takes to make the 3.0.x series viable.
Raymond
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
