| msg87968 - (view) |
Author: Georg Brandl (georg.brandl) *  |
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) * |
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) * |
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) * |
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) * |
Date: 2009-05-17 12:15 |
| Would inheriting from MutableMapping fix this problem? |
|
|
| msg87996 - (view) |
Author: Martin v. Löwis (loewis) * |
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) * |
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) * |
Date: 2010-12-04 15:22 |
| See also #9523. |
|
|
| msg127845 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-02-04 00:56 |
| I believe this is now superseded by #9523, which has less discussion but a patch. |
|
|