classification
Title: Add more dict methods to dbm interfaces
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Improve dbm modules
View: 9523
Assigned To: Nosy List: eric.araujo, foobaron, georg.brandl, loewis, pablomouzo, pitrou
Priority: normal Keywords:

Created on 2009-05-17 08:46 by georg.brandl, last changed 2011-02-04 00:56 by eric.araujo. This issue is now closed.

Messages (10)
msg87968 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-05-17 08:46
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.
msg87987 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-17 11:05
> 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.
msg87990 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-05-17 11:33
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.
msg87991 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-17 11:58
>> 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.
msg87993 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-05-17 12:15
Would inheriting from MutableMapping fix this problem?
msg87996 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-17 14:52
> 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).
msg91342 - (view) Author: Christopher Lee (foobaron) Date: 2009-08-06 01:08
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: Issue 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.
msg123323 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-12-04 09:15
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.
msg123359 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-04 15:22
See also #9523.
msg127845 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-02-04 00:56
I believe this is now superseded by #9523, which has less discussion but a patch.
History
Date User Action Args
2011-02-04 00:56:40eric.araujosetstatus: open -> closed
nosy: loewis, georg.brandl, pitrou, eric.araujo, foobaron, pablomouzo
messages: + msg127845

superseder: Improve dbm modules
resolution: duplicate
stage: needs patch -> resolved
2010-12-04 15:22:48eric.araujosetnosy: + eric.araujo
messages: + msg123359
2010-12-04 09:15:38georg.brandlsetpriority: critical -> normal
versions: + Python 3.3, - Python 3.1
title: Fix dbm interfaces -> Add more dict methods to dbm interfaces
messages: + msg123323

type: behavior -> enhancement
2010-01-23 04:00:24pablomouzosetnosy: + pablomouzo
2009-08-06 01:08:10foobaronsetnosy: + foobaron
messages: + msg91342
2009-05-17 14:52:56loewissetmessages: + msg87996
2009-05-17 12:15:09pitrousetnosy: + pitrou
messages: + msg87993
2009-05-17 11:58:24loewissetmessages: + msg87991
2009-05-17 11:33:26georg.brandlsetpriority: release blocker -> critical

messages: + msg87990
2009-05-17 11:05:34loewissetnosy: + loewis
messages: + msg87987
2009-05-17 08:47:12georg.brandllinkissue5937 superseder
2009-05-17 08:46:28georg.brandlcreate