All the dbm.* modules currently have different interfaces, and different
levels of supporting the Python3-style dictionary interface -- while the
docs claim they all have (most of) the dict interface.

For example, both dbm.gnu and dbm.ndbm only have keys() methods, and
they return a list. Etc. for other dict-style methods.

So, either we remove the claim that they have a dict-style interface
beyond __*item__() and keys(), or we do something about it.

So, either we remove the claim that they have a dict-style interface
beyond __*item__() and keys(), or we do something about it.

I disagree that this is release-critical. I think it is desirable to
say that the dbm modules support most of a dict-style interface,
and I also think that it is factually correct to claim that they
currently do.

The problem with the current documentation is that it apparently stopped
documenting the "dict-style interface", in the sense

http://www.python.org/doc/2.5/lib/typesmapping.html

did. Instead, the documentation now only documents the dict type itself.
If a dict-style interface was specified, one would have to specify
whether returning views from keys/values/items is part of the dict-style
interface or not.

First, lowering priority.

I disagree that this is release-critical. I think it is desirable to
say that the dbm modules support most of a dict-style interface,
and I also think that it is factually correct to claim that they
currently do.

Supporting only __getitem__, __setitem__, __delitem__, __contains__ and
keys is already "most of a dict-style interface"? Only dumbdbm and
bsddb, which isn't in the core anymore, support more methods.

The problem with the current documentation is that it apparently stopped
documenting the "dict-style interface", in the sense
http://www.python.org/doc/2.5/lib/typesmapping.html
did. Instead, the documentation now only documents the dict type itself.
If a dict-style interface was specified, one would have to specify
whether returning views from keys/values/items is part of the dict-style
interface or not.

It should first be decided what a "dict-style interface" means in Python
3, then I can document it :)

However, for the dbm modules I would be in favor of only specifying the
four mentioned methods, as in the docstring of dbm/init.py, and not
claiming any more.

> I disagree that this is release-critical. I think it is desirable to
> say that the dbm modules support most of a dict-style interface,
> and I also think that it is factually correct to claim that they
> currently do.

Supporting only __getitem__, __setitem__, __delitem__, __contains__ and
keys is already "most of a dict-style interface"?

It's also __len__... Indeed, I think that this is the major part of the
dict interface. For a number of additional methods, it would be
straight-forward to support them as well (such as get(), pop(),
popitem(), setdefault(), update()). That they are missing should be
considered as a regular bug/missing feature. However, it appears that
nobody has complained about those missing features in all these years,
so that they are missing can't be that serious.

However, for the dbm modules I would be in favor of only specifying the
four mentioned methods, as in the docstring of dbm/init.py, and not
claiming any more.

I don't mind the documentation to explain precisely what is, as long as
it continues to explain what could be.

Would inheriting from MutableMapping fix this problem?

Would inheriting from MutableMapping fix this problem?

In principle: some of it, yes. These types are written in C,
so I'm not sure how exactly it would work. Also, it
still wouldn't provide all methods, e.g. copy(), fromkeys(),
get(), values(), items() would still be missing, as would
iteration (although the dict documentation apparently never
says that iterating over a dict is supported).

I suspect that for most users, shelve is the main way they will access
the dbm.* interfaces. Based on that, the dict methods that are really
needed on dbm.* objects are just: __iter__, __len__, __getitem__,
__setitem__, __delitem__, __contains__, has_key, and keys.

Note: bpo-5736 aims to make dbm.* support the iterator protocol, which
would be crucial for making shelve iteration scalable (currently,
iterating on a Shelf will call self.dict.keys(), loading the entire
index into memory!).

The dbm.* docs could also explicitly tell users who want a *complete*
dict interface to create a class that inherits from both dbm and
UserDict.DictMixin / MutableMapping.

r87013 adds get() and setdefault() to dbm.gnu -- now gdbm and ndbm have the same set of dict methods available.

For me, that is enough to demote this to feature request.

There's another issue anyway for iteration protocol support.

See also bpo-9523.

I believe this is now superseded by bpo-9523, which has less discussion but a patch.