You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2011-02-04.00:56:40.284>created_at=<Date2009-05-17.08:46:28.206>labels= ['type-feature', 'library']
title='Add more dict methods to dbm interfaces'updated_at=<Date2011-02-04.00:56:40.283>user='https://github.com/birkenfeld'
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
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.
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?
loewis commented on May 17, 2009
loewismannequin
Mannequin
More actions
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).
foobaron commented on Aug 6, 2009
foobaronmannequin
Mannequin
More actions
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.
Activity
birkenfeld commentedon May 17, 2009
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.
loewis commentedon May 17, 2009
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.
birkenfeld commentedon May 17, 2009
First, lowering priority.
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.
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.
loewis commentedon May 17, 2009
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.
I don't mind the documentation to explain precisely what is, as long as
it continues to explain what could be.
pitrou commentedon May 17, 2009
Would inheriting from MutableMapping fix this problem?
loewis commentedon May 17, 2009
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).
foobaron commentedon Aug 6, 2009
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.
birkenfeld commentedon Dec 4, 2010
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.
[-]Fix dbm interfaces[/-][+]Add more dict methods to dbm interfaces[/+]merwok commentedon Dec 4, 2010
See also bpo-9523.
merwok commentedon Feb 4, 2011
I believe this is now superseded by bpo-9523, which has less discussion but a patch.