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

[py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) #45348

Closed
larryhastings opened this issue Aug 24, 2007 · 4 comments
Assignees
Labels
stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@larryhastings
Copy link
Contributor

BPO 1007
Nosy @gpshead, @larryhastings
Files
  • lch.py3k.dumbdb.contains.diff.1.txt
  • 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/gpshead'
    closed_at = <Date 2007-08-24.22:00:11.613>
    created_at = <Date 2007-08-24.00:48:54.729>
    labels = ['library', 'type-crash']
    title = '[py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly)'
    updated_at = <Date 2007-09-02.20:02:27.123>
    user = 'https://github.com/larryhastings'

    bugs.python.org fields:

    activity = <Date 2007-09-02.20:02:27.123>
    actor = 'loewis'
    assignee = 'gregory.p.smith'
    closed = True
    closed_date = <Date 2007-08-24.22:00:11.613>
    closer = 'gregory.p.smith'
    components = ['Library (Lib)']
    creation = <Date 2007-08-24.00:48:54.729>
    creator = 'larry'
    dependencies = []
    files = ['8303']
    hgrepos = []
    issue_num = 1007
    keywords = ['patch']
    message_count = 4.0
    messages = ['55233', '55234', '55276', '55277']
    nosy_count = 2.0
    nosy_names = ['gregory.p.smith', 'larry']
    pr_nums = []
    priority = 'normal'
    resolution = 'accepted'
    stage = None
    status = 'closed'
    superseder = None
    type = 'crash'
    url = 'https://bugs.python.org/issue1007'
    versions = ['Python 3.0']

    @larryhastings
    Copy link
    Contributor Author

    THIS PATCH IS FOR PYTHON 3000. (There's currently no Python 3000 entry
    in the "Versions" list.)

    As of revision 57341 (only a couple hours old as of this writing),
    test_shelve was failing on my machine. This was because I didn't have
    any swell databases available, so anydbm was falling back to dumbdbm,
    and dumbdbm had a bug. In Py3k, dumbdbm's dict-like interface now
    requires byte objects, which it internally encodes to "latin-1" then
    uses with a real dict. But dumbdbm.__contains__ was missing the
    conversion, so it was trying to use a bytes object with a real dict, and
    that failed with an error (as bytes objects are not hashable). This
    patch fixes dumbdbm.__contains__ so it encodes the key, fixing
    test_shelve on my machine.

    But there's more! Neil Norvitz pointed out that test_shelve didn't fail
    on his machine. That's because dumbdbm is the last resort of anydbm,
    and he had a superior database module available. So the regression test
    suite was really missing two things:

    * test_dumbdbm should test dumbdbm.\_\_contains__.
    * test_anydbm should test all the database modules available, not
    

    merely its first choice.

    So this patch also adds test_write_contains() to test_dumbdbm, and a new
    external function to test_anydbm: dbm_iterate(), which returns an
    iterator over all database modules available to anydbm, and internally
    forces anydbm to use that database module, restoring anydbm to its first
    choice when it finishes iteration. I also renamed _delete_files() to
    delete_files() so it could be the canonical dbm cleanup function for
    other tests.

    While I was at it, I noticed that test_whichdbm.py did a good job of
    testing all the databases available, but with a slightly odd approach:
    it iterated over all the possible databases, and created new test
    methods--inserting them into the class object--for each one that was
    available. I changed it to use dbm_iterate() and delete_files() from
    test.test_anydbm, so that that logic can live in only one place. I
    didn't preserve the setattr() approach; I simply iterate over all the
    modules and run the tests inside one conventional method.

    @larryhastings larryhastings added stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump labels Aug 24, 2007
    @larryhastings
    Copy link
    Contributor Author

    Whoops, copy & paste error on the title, there.

    @larryhastings larryhastings changed the title ix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Aug 24, 2007
    @gps gps mannequin changed the title Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) [py3k] Fix dumbdbm, which fixes test_shelve (for me); instrument other tests so we catch this sooner (and more directly) Aug 24, 2007
    @gpshead gpshead self-assigned this Aug 24, 2007
    @gpshead
    Copy link
    Member

    gpshead commented Aug 24, 2007

    looks like someone already committed the one liner dumbdbm latin-1 fix.
    But the meat of this patch is the unit test improvements.

    I had to fix test_whichdb to exclude dumbdbm as that has no file for
    whichdb to test.

    committed to py3k as r57419

    @gpshead gpshead closed this as completed Aug 24, 2007
    @larryhastings
    Copy link
    Contributor Author

    Yeah, Neil Norwitz added the one-line dumbdbm fix in r57358.

    Thanks!

    @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
    Labels
    stdlib Python modules in the Lib dir type-crash A hard crash of the interpreter, possibly with a core dump
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants