Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Deprecate nonstandard behavior of a dumbdbm database #65907

Closed
serhiy-storchaka opened this issue Jun 10, 2014 · 9 comments
Closed

Deprecate nonstandard behavior of a dumbdbm database #65907

serhiy-storchaka opened this issue Jun 10, 2014 · 9 comments
Assignees
@serhiy-storchaka
Labels
stdlib Python modules in the Lib dir type-feature A feature request or enhancement

Comments

@serhiy-storchaka
Copy link
Member

BPO 21708
Nosy @rhettinger, @bitdancer, @PCManticore, @serhiy-storchaka
Files
  • dbm_dumb_deprecations.patch
  • dbm_dumb_deprecations2.patch
    		•

    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 = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2016-07-17.08:38:20.164>
created_at = <Date 2014-06-10.18:31:22.211>
labels = ['type-feature', 'library']
title = 'Deprecate nonstandard behavior of a dumbdbm database'
updated_at = <Date 2016-07-17.08:38:20.163>
user = 'https://github.com/serhiy-storchaka'

    bugs.python.org fields:

    activity = <Date 2016-07-17.08:38:20.163>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2016-07-17.08:38:20.164>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2014-06-10.18:31:22.211>
creator = 'serhiy.storchaka'
dependencies = []
files = ['35558', '43477']
hgrepos = []
issue_num = 21708
keywords = ['patch']
message_count = 9.0
messages = ['220185', '221212', '221448', '221490', '221500', '221521', '242965', '268874', '269873']
nosy_count = 5.0
nosy_names = ['rhettinger', 'r.david.murray', 'Claudiu.Popa', 'python-dev', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21708'
versions = ['Python 3.6']
    @serhiy-storchaka
    Copy link
    Member Author

    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 deprecation period is needed.

    Here is a patch (based on patch by Claudiu Popa, submitted in bpo-18039), which adds deprecation warnings for cases when current behavior differs from desired: invalid values for the flag parameter (will raise ValueError in future), opening non-existing database in 'r' or 'w' mode (will raise dbm.dumb.error), modifying a database opened for reading only (will raise dbm.dumb.error).

    This patch needs approving by other core developer.

    @serhiy-storchaka serhiy-storchaka self-assigned this Jun 10, 2014
    @serhiy-storchaka serhiy-storchaka added the type-feature A feature request or enhancement label Jun 10, 2014
    @rhettinger
    Copy link
    Contributor

    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 overkill on the string splits:

    + with self.assertWarnsRegex(DeprecationWarning,
    + "The database file is missing, the "
    + "semantics of the 'c' flag will "
    + "be used."):

    @serhiy-storchaka
    Copy link
    Member Author

    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 worry about performance hit of such checks, __setitem__ and __delitem__ are expensive operations doing file I/O.

    @rhettinger
    Copy link
    Contributor

    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 mode is worthwhile.

    @bitdancer
    Copy link
    Member

    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 be printed once per run of python, unless I'm completely misremembering how deprecation warnings work.

    @rhettinger
    Copy link
    Contributor

    Feel free to ignore my advice and make unnecessary changes to a very old, stable API.

    @rhettinger rhettinger removed their assignment Jun 25, 2014
    @serhiy-storchaka
    Copy link
    Member Author

    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.

    @serhiy-storchaka
    Copy link
    Member Author

    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.

    @serhiy-storchaka serhiy-storchaka added the stdlib Python modules in the Lib dir label Jun 19, 2016
    @serhiy-storchaka serhiy-storchaka self-assigned this Jun 19, 2016
    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 6, 2016

    New changeset 62da75b29b29 by Serhiy Storchaka in branch 'default':
    Issue bpo-21708: Deprecated dbm.dumb behavior that differs from common dbm
    https://hg.python.org/cpython/rev/62da75b29b29

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @serhiy-storchaka serhiy-storchaka

    Labels
    stdlib Python modules in the Lib dir type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @bitdancer @rhettinger @serhiy-storchaka