[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Roundup Robot added the comment: New changeset 62da75b29b29 by Serhiy Storchaka in branch 'default': Issue #21708: Deprecated dbm.dumb behavior that differs from common dbm https://hg.python.org/cpython/rev/62da75b29b29 -- nosy: +python-dev ___

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Serhiy Storchaka added the comment: Patch updated. Added What's New entry. We already lost 2 years and the 3.5 release. I don't want to lost 3.6 too. -- assignee: -> serhiy.storchaka components: +Library (Lib) versions: +Python 3.6 -Python 3.5 Added file:

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Serhiy Storchaka added the comment: Warnings are not raised by default. They are raised only when the database is opened with the 'r' mode and then modified. The earlier we start deprecation period, the earlier we could add true read-only and update existing modes to dbm.dumb. --

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Serhiy Storchaka added the comment: Thanks Raymond for your attention. Readonly warnings are emitted only when dumpdbm database opened in read only mode. They will be turned into exceptions in future (3.6 or 3.7). Annoying warnings on changed in future operations is desirable effect. If you

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Raymond Hettinger added the comment: I'm not worries about the performance. I think the warnings and checks don't need to be there are all (API creep). AFAICT, this has never been requested or needed in the entire history of the dumbdbm. Your original goal of changing the default update

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

R. David Murray added the comment: The point is to make the API consistent. So if the other dbm modules raise an error when __setitem__/__delitem__ are called on an R/O db, then the warnings are appropriate (but should mention that this will be an error in the future). The warnings will only

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Raymond Hettinger added the comment: Feel free to ignore my advice and make unnecessary changes to a very old, stable API. -- assignee: rhettinger - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21708

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Raymond Hettinger added the comment: The core idea is reasonable. The patch overreaches by adding readonly warnings to __setitem__ and __delitem__ which will spew-out on every call (these could be ignored or set to warn once by the user but that is PITA). Minor nit. We have a little PEP-8

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: serhiy.storchaka - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21708 ___

[issue21708] Deprecate nonstandard behavior of a dumbdbm database

New submission from Serhiy Storchaka: Unlike to other dbm implementations, a dumpdbm database is always opened for update, and will be created if it does not exist. We can fix this discrepancy and implement common behavior for 'r' and 'w' modes, but this will change current behavior and some