homepage

Crash on Python 2.7 branch.
$ ./python -We -c 'import anydbm'
python: Objects/dictobject.c:759: PyDict_SetItem: Assertion `value' failed.
Abandon
It occurs with all optional modules compiled.

Actually, the issue seems to be in bsddb.
$ ./python -We -c 'import bsddb'
python: Objects/dictobject.c:759: PyDict_SetItem: Assertion `value' failed.
Abandon

It is probably related to the CObject PendingDeprecationWarning.
For the record, bsddb does not use the new Capsule API in Python 2.7.
ref: http://bugs.python.org/issue7992#msg104140 

Importing "bsddb" crashes. Importing "bsddb3" (the updated version I keep independiently of python) DOESN'T crash.
bsddb = 4.8.4
bsddb3 = 5.0.0 (currently).
Checking the changelog, I see this possible cause:
"""
 * Capsule support was buggy. The string passed in to PyCapsule_New() must outlive the capsule. (Larry Hastings)
"""
It is 3AM in Spain now. Will check when I find some time.

The crash is triggered because PyDict_SetItemString(d, "api", py_api) is called with py_api=NULL when PyCObject_FromVoidPtr returns an error.
A possible workaround is to create a copy of PyCObject_FromVoidPtr (e.g. _PyCObject_FromVoidPtr) which is free of warnings.
This function will be used by the _bsddb module in Python 2.7.
See patch.

The problem is that the "-We" is converting the CObject use to ERRORs, when this API is perfectly legal in Python 2.7.
bsddb 4.8.4 DOES *legally* uses CObjects in Python 2.7.
In pybsddb 5.0.0 I migrated to Capsule, since 5.0 doesn't support python 3.0 anymore (python 3.0 didn't support capsule).
I can commit a "4.8.4.1" version with Capsule support, for I think this crash is overzealot. 
According to http://bugs.python.org/issue7992#msg104140 , CObject is not actually deprecated in Python 2.7, so it should not cause CObjects use with "-We" to be an error. Read the mail thread. In particular: http://mail.python.org/pipermail/python-committers/2010-April/000882.html .
I would suggest to drop DeprecationWarnings for CObjects in 2.7.1.
Comments?.

In the spirit of moving this forward:
http://mail.python.org/pipermail/python-dev/2010-September/104201.html 

Move the CObject use to a py3k warning instead of an error in r86178.
I still need to solve improve error management in bsddb. This bug remains open for a while.

Better bsddb error control. Please, review.
"""
[jcea@babylon5 release27-maint]$ ./python
Python 2.7.0+ (release27-maint:86176:86178M, Nov 5 2010, 00:30:) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> exit()
"""
"""
[jcea@babylon5 release27-maint]$ ./python -3
Python 2.7.0+ (release27-maint:86176:86178M, Nov 5 2010, 00:30:) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
__main__:1: DeprecationWarning: in 3.x, the bsddb module has been removed; please use the pybsddb project instead
/home/python/svn-hg/release27-maint/Lib/bsddb/__init__.py:67: DeprecationWarning: CObject type is not supported in 3.x. Please use capsule objects instead.
 import _bsddb
"""
"""
[jcea@babylon5 release27-maint]$ ./python -3 -Werror
Python 2.7.0+ (release27-maint:86176:86178M, Nov 5 2010, 00:30:)
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.filterwarnings('ignore',
... "in 3.x, the bsddb module has been removed; please use the pybsddb project instead",
... category=DeprecationWarning)
>>> import bsddb
Exception DeprecationWarning: DeprecationWarning('CObject type is not supported in 3.x. Please use capsule objects instead.',) in <module '_bsddb' (built-in)> ignored
>>> exit()
"""
Why is my "PyErr_Warn()" not being printed?
The code: (py_api is the CObject, will be NULL if an exception happened)
"""
 if (py_api) {
 PyDict_SetItemString(d, "api", py_api);
 Py_DECREF(py_api);
 } else { /* Something bad happened */
 PyErr_WriteUnraisable(m);
 PyErr_Warn(PyExc_RuntimeWarning,
 "_bsddb/_pybsddb C API will be not available");
 PyErr_Clear();
 }
"""
Commit r86180.
Now I have to up-port this patch to the upcoming pybssddb 5.1.1.