[Raymond]

>> > IIRC, dbhash and bsddb don't affect the Apple MacIntosh users.

[Skip]

I don't know what you mean here. Do you mean Mac OS 9 or Mac OS X? I use bsddb all the time on Mac OS X.

Hmm, I'll have to fix the docs too. They currently list bsddb as being only for Unix and Windows. [Skip]

What are we discussing? Just adding an iterator to objects opened with the old bsddb API?

Yes. Iterators and the rest of the mapping API (__iter__, pop, popitem, iteritems, setdefault, etc). Like dumbdbm and shelve, this is done by including UserDict.DictMixin as a base class. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################

Raymond writes:

[Raymond]

...

>> > IIRC, dbhash and bsddb don't affect the Apple MacIntosh users.

[Skip]

...

I don't know what you mean here. Do you mean Mac OS 9 or Mac OS X? I use bsddb all the time on Mac OS X.

Hmm, I'll have to fix the docs too. They currently list bsddb as being only for Unix and Windows.

While you are at it, please add a few more examples of how to use "bsddb3" in particular the "dbtables" section. Like how do you select all from a table. JD

[Raymond]

...

...

...

I would like to backport this patch to Py2.3.1. The effort to provide a full mapping interface to all mapping like objects was attempted in Py2.3 and several modules for the bsddb package were updated, but this one was missed and the package was left half converted.

IIRC, dbhash and bsddb don't affect the Apple MacIntosh users. Also, since this effort was started for bsddb and only half completed, I view it to be a bit of a bugfix as well as being featurelike. It certainly affects the usability of the module (the looping example and related text in the docs were both wrong -- that would not have happened if the normal looping expectations were supported). [GvR] Can you discuss this on python-dev? [Raymond] Guys, are you okay with backporting this? [Jeremy] Isn't this just the sort of little feature that was the subject of recent discussion on the dangers of backporting. It would mean that someone writing an app against Python 2.3 could never be sure whether the feature existed. In practice, that would mean developers using 2.3.x would only find out about problems after deployment when they bump into a user with the original 2.3.

I'm not sure how convincing I find this argument, but it's got some merit.

It has some. That's why GvR had me bring it to python-dev so you guys could help decide on the proper balance. But for that one thought, the decision to apply is clear cut. Thoughts in favor of applying: * the existing interface is a pain and is misdocumented in Py2.3.0 * the patch was already half complete for 2.3.0 (applied to dbobj and dbshelve) __init__.py was just missed). * the patch was already applied to dumbdbm and shelve for Py2.3.0 * if needed, it's not hard to write code that automatically adjusts for Py2.3.0: if not f.__class__.__bases__: f.__class__.__bases = (UserDict.DictMixin,) * waiting another 18 months to put this in just results in that many more installed Pythons out there without the patch Raymond

[Raymond]

...

It has some. That's why GvR had me bring it to python-dev so you guys could help decide on the proper balance. But for that one thought, the decision to apply is clear cut.

[Martin]

There is no proper balance. If you believe in the policy "no new features", this policy is absolute - it would be pointless to accept some new features, but reject others on grounds of the policy.

This policy is mutually exclusive with "new features are fine as long as they don't break anything". You can get opinions, but you cannot get consensus.

Well put! Even bugfixes are features in that something will work under Py2.3.1 that won't work under Py2.3.0. So, even an absolutist policy on our end shouldn't create a false sense of security or relieve a developer from testing his or her application on the lowest numbered Python for which it is claimed to run (including micro-releases). That has always been true. If you developed something under Py2.2.3 and expected it to run under Py2.2.0, the only way to be sure would be to test it with Py2.2.0. In this particular case, we are (IMHO) much better off adding an iterable interface than leaving current situation with "db.first()" and "while 1: db.next()" wrapped in a try/except for an undocumented exception class -- yuck. Worse still, the docs for Py2.3.0 cannot be changed and they are wrong on several counts (the methods return items instead of keys; EOF is signaled by an exception instead of None; and the example doesn't run). Raymond ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################

On Sun, 2003-09-14 at 18:08, Martin v. Löwis wrote:

"Raymond Hettinger" writes:

...

In this particular case, we are (IMHO) much better off adding an iterable interface than leaving current situation with "db.first()" and "while 1: db.next()" wrapped in a try/except for an undocumented exception class -- yuck.

As nobody has protested against this specific change (yet?), I guess you can go ahead and apply it. In doing so, you have to accept the burden of taking blame in case this turns out to be a bad idea.

Perhaps we could wait to hear from Jack or Just or someone who was concerned about feature creep in maintenance releases. I think we should decide now whether to follow the policy they propose or we should drop it. Right now, it feels like it's in limbo. Jeremy

-----Original Message----- From: python-dev-bounces@python.org [mailto:python-dev-bounces@python.org]On Behalf Of Tim Peters Sent: Sunday, September 14, 2003 6:36 PM To: jeremy@alum.mit.edu; Martin v. Löwis Cc: Raymond Hettinger; python-dev@python.org Subject: RE: [Python-Dev] python/dist/src/Lib/bsddb __init__.py,1.5,1.6

[Jeremy]

...

Perhaps we could wait to hear from Jack or Just or someone who was concerned about feature creep in maintenance releases. I think we should decide now whether to follow the policy they propose or we should drop it. Right now, it feels like it's in limbo.

Guido needs to set the direction here. Slamming new features into micro releases became irresistible after the 1.5.2 experience, where a very long time passed without a new Python release (not even a bugfix release). That naturally caused people to want to get every improvement in ASAP.

We were able to counteract that successfully in the early days of PythonLabs, because then we pumped out two minor releases per year, and it was much easier to sell "leave the micro release a pure bugfix release -- the next minor release is only a few months away".

Then 2.3 stretched out over 18 months, and there's no plan for 2.4 in evidence yet. Given this most recent history, and the unlikelihood that PythonLabs's (or a workalike equivalent's) early days will repeat itself soon, if I had a minor feature I really wanted to get in, I'd try to get it into a 2.3 micro release.

OTOH, if Guido decides to go back to a schedule-driven release for 2.4, and it's not terribly far in the future, then it will again be much easier to sell 2.3 micro releases as bugfix-only (and stick to that).

We're all pretty creative about what we'll call "a bug", when it suits a feature we believe in <0.7 wink>.

So, what we need is a plan for a 2.4 release, then. How soon would it need to be, though? And who can commit time to making it happen. Seems to me that some formerly active core developers are currently busy in other realms. Is it feasible to have a 2.4 plan, or are we ready to contemplate (gasp) 3.0? What help can such as I, not a practiced C coder and fairly heavily committed and thinly spread, be? regards -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/

On Mon, 2003-09-15 at 08:51, A.M. Kuchling wrote:

I'd be in favor of setting an arbitrary date for a 2.4 release, and when that date rolls around stabilizing and releasing the CVS tree, no matter what's been implemented or not implemented. If we've made major language revisions by that time, fine, but it's worthwhile even if 2.4 is just 2.3 + (various bugfixes deemed too risky for 2.3.1) + (a few new modules).

PEP 320 estimates February 2005, a 19-month gap matching that between 2.2 and 2.3. That seems a bit too long, especially if there are no large changes that require testing; aiming for autumn 2004, beginning to freeze in August, seems reasonable.

+1 -Barry

On Mon, 2003-09-15 at 10:44, Tim Peters wrote:

I'd like to see 2.4 released no later than 29-Jul-2004.

I like the tradition this sets. I can't think of a better birthday present to one of the best Canadian bassists in the world. -Barry

On Mon, 2003-09-15 at 08:51, A.M. Kuchling wrote:

I'd be in favor of setting an arbitrary date for a 2.4 release, and when that date rolls around stabilizing and releasing the CVS tree, no matter what's been implemented or not implemented. If we've made major language revisions by that time, fine, but it's worthwhile even if 2.4 is just 2.3 + (various bugfixes deemed too risky for 2.3.1) + (a few new modules).

PEP 320 estimates February 2005, a 19-month gap matching that between 2.2 and 2.3. That seems a bit too long, especially if there are no large changes that require testing; aiming for autumn 2004, beginning to freeze in August, seems reasonable.

In the absence of any plans for major new features, I think this is a good plan. A rough schedule might be: 2.4a1 April 2.4a2 late May/early June 2.4b1 July 9 2.4b2 Aug. 6 2.4 f Sep. 3 We should also make a plan for a 2.3 maintenance release. There have been a lot of checkins, but I haven't gotten a sense for how significant the bugs were. Jeremy

On Mon, 2003-09-15 at 11:03, Neal Norwitz wrote:

I think 2.3 has been great! There were a few memory leaks plugged. I don't even recall any crashes specific to 2.3. I'm very happy with the apparent robustness of 2.3. Maybe nobody is using it? :-)

I'm using it for everything, and I agree! It's a very solid release. I still think we should plan for a 2.3.1 soonish, but the hold up may just be finding a release manager to own it. I'd rather spread the love this time. :)

As far as the release schedule for 2.4, I haven't heard any squawking recently about Python changing too fast.

We can't let that stand, now can we? :) Maybe Guido can post about his big plans for 2.4. There's still time to get PEPpy too. -Barry

Barry> On Mon, 2003-09-15 at 11:03, Neal Norwitz wrote: >> I think 2.3 has been great! There were a few memory leaks plugged. >> I don't even recall any crashes specific to 2.3. I'm very happy with >> the apparent robustness of 2.3. Maybe nobody is using it? :-) Barry> I'm using it for everything, and I agree! Ditto on my development machine, except I just cvs up periodically, so I'm generally running from CVS as of a few days ago, not even 2.3. I do intend to update to 2.3 on the Mojam webserver in a short while. That should provide a nice speed boost over the 2.2.3 I'm currently running there. >> As far as the release schedule for 2.4, I haven't heard any squawking >> recently about Python changing too fast. Barry> We can't let that stand, now can we? :) I suspect that's simply because the focus was on library and performance improvements instead of new language features. Barry> There's still time to get PEPpy too. I would like to get back to PEP 304 (Control of pyc file location). I got stuck when someone raised some good objections about how it would play on Windows with it's multiple rooted file system, but if those problems can be ironed out I think it would be a good addition to the system. Skip

Is it worth holding 2.3.1 until after Panther ships, on the assumption that its release will turn up more users and more bugs? If not, 2.3.1's timing can probably be left up to the release manager, who can make the release whenever he feels like it.

Last month, we worked out a tentantive plan to start the 2.3.1 release process in the third week of September. I think we should stick with that. The initial round of bugfixes is an important step for 2.3 being viewed as stable and to show everyone that development/support has not vanished. If critical bugs surface later, that can be a consideration for 2.3.2. There is no reason to be stingy with the initial bugfix release. Raymond ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################