[Python-Dev] Python 3.0.1
python at rcn.com
Fri Jan 30 00:27:03 CET 2009
> 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:
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
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.
More information about the Python-Dev