Deprecations won't spontaneously appear in a micro release

In case you don't know, sets.BaseSet.update() has been deprecated in favor of union_update() in order to cut out the unneeded duplication of functionality in Python 2.4 . While 2.3.1 was still under development it grew a PendingDeprecationWarning. This did not sit well with some people.

The argument for the PendingDeprecationWarning was that it is silent by default and gives people a heads-up in terms of things that are known to be deprecated in the next minor version of Python.

Against this idea, the argument that it adds a change between micro versions that is not a bug fix was raised. In the end this won.

Contributing threads:

• pending deprecation warning for Set.update

Web-SIG on its way, supposedly

Bill Janssen is working on a charter so a Web SIG can be started in order to redesign the cgi module as the main goal, but also just making Python friendlier to web coding in general.

Contributing threads:

• Improving the CGI module

Threads and the desolation that is shutdown

Tim Peters decided to try to deal with the fact that the Zope 3 testing suite was spitting out a ton of messages about unhandled exceptions during shutdown of the interpreter. It turned out that threads were still running during shutdown and thus were throwing a fit because they were accessing module globals that were being torn down and set to None.

The problem went away when the second call to PyGC_Collect() in Py_Finalize() was commented out. This is not totally acceptable since the second call is there to help collect garbage at shutdown so that things clean up properly. Tim did end up suggesting just taking it out, though, for a future version of Python.

He also suggested tearing down the sys module even later (and thus "even more of a special case than it is now"). This would leave sys.modules around and thus not cause globals to turn to None and cause errors from that side-effect.

Neither solution has been taken yet. A temporary solution if you keep running into this is to make sure that either your cleanup code only accesses local variables (if you have to store references to globals since that will keep them around for you during shutdown).

Contributing threads:

• Fun with 2.3 shutdown

Where is str.rsplit?!?

The reason str.rsplit does not exist in Python is because the method is not difficult to code on your own. And yet people still want it. But there was not of a public outcry and the topic just fizzled.

Contributing threads:

• Discussion on adding rsplit() for strings and unicode objects.

Waxing on PEP 310

Holger Krekel brought up PEP 310 (entitled "Reliable Acquisition/Release Pairs") in terms of how code blocks should handle exceptions and such. Michael Hudson suggested that might be taking PEP 310 beyond what it is meant to cover. To this, Holger suggested that then perhaps some other route should be taken.

As with all PEPs, discussion of them is always helpful for python-dev and the community. It helps hash out ideas and gives python-dev feedback on whether a PEP should be rejected.

Contributing threads:

pep 310 (reliable acquisition/release pairs)

bsddb3 failures and the database system it wraps, news at 10

The bsddb3 regression tests were failing during preparation for Python 2.3.1 . Beyond the "the test just fails sometimes" issues that come up with tests that are finicky because of timing, it was suggested that the failures are the fault of the Sleepycat DB code. It is still being looked into.

Contributing threads:

• latest bsddb3 test problems

We want you to help with the war on SF patch items

Someone wanted to help but wasn't sure how they could. Martin v. Loewis sent an email listing common things anyone can do to help with dealing with the patch items on SourceForge. The email can be found at http://mail.python.org/pipermail/python-dev/2003-September/038253.html .

Contributing threads:

• Help offered

Python glossary

Skip Montanaro converted the glossary he has as a wiki at http://manatee.mojam.com/python-glossary to the proper format to be included in the Python documentation. You can peruse the glossary as it stands in the documentation at http://www.python.org/dev/doc/devel/tut/node16.html. Thanks to Skip for for doing the grunt work and getting this done.

If you wish to help, please visit the wiki and add/edit/whatever .

Contributing threads:

• Python Glossary

Mitch Kapor to speak at PyCon 2004

Mitch Kapor is founder of the Open Source Application Foundation (OSAF), co-founder of the Electronic Frontier Foundation, and developer of Chandler . He is going to be the keynote speaker at PyCon 2004 .

The general Call for Proposals has gone out. If you have any desire to speak at PyCon take a look at the CFP.

Python 2.3.1 released, people were happy... initially

Python 2.3.1 was released to the general public. It was meant to be a bug-fix release to fix bugs that were discovered after Python 2.3 went out the door.

But then a typo in the configure.in script that prevented os.fsync() from ever being included was discovered. A rather vocal group of users of this function got out their pitchforks and torches while screaming, "blood, blood!" (actually they were nice about it, but saying, "they kindly asked for a new release," isn't that dramatic, is it?)

How were the rioting masses (who were actually not rioting) appeased?

Contributing threads:

• 2.3.1 is (almost) a go
• RELEASED Python 2.3.1
• How to test for stuff like fsync?

Let them eat cake while releasing Python 2.3.2

Python 2.3.2 was released to deal with the os.fsync() snafu. HP/UX compiling issues were also addressed.

The bsddb3 problems are still there, but it is becoming more and more certain that the issues are with Sleepycat and not the bsddb module.

Contributing threads:

• plans for 2.3.2
• Python2.3.2 and release23-maint branch
• 2.3.2 and bsddb
• RELEASED Python 2.3.2, release candidate 1
• OpenSSL vulnerability
• RELEASED Python 2.3.2 (final)