Several improvement point of gdbm module

[corona10]

BPO	45503
Nosy	@methane, @serhiy-storchaka, @corona10

^{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 = None
closed_at = None
created_at = <Date 2021-10-17.11:35:30.222>
labels = ['type-feature', 'library', '3.11']
title = 'Several improvement point of gdbm module'
updated_at = <Date 2021-10-17.11:35:45.741>
user = 'https://github.com/corona10'

bugs.python.org fields:

activity = <Date 2021-10-17.11:35:45.741>
actor = 'corona10'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-10-17.11:35:30.222>
creator = 'corona10'
dependencies = []
files = []
hgrepos = []
issue_num = 45503
keywords = []
message_count = 1.0
messages = ['404136']
nosy_count = 3.0
nosy_names = ['methane', 'serhiy.storchaka', 'corona10']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue45503'
versions = ['Python 3.11']

[corona10]

I have a chance to exchange mail with gdbm module maintainer Sergey Poznyakoff to supporting the crash tolerance feature.
(See bpo-45452)

Other dbm modules also might have the same issue what the maintainer pointed out.

I copy and paste the content that gdbm maintainer's pointed out.

I would like to listen to other core dev's opinions about the gdbm moudle and also other dbm module interface improvements.
I add the core devs who might have an interest in this issue.

Personally, I have interests in Error handling and items() and values() methods issues.

1. Error handling

The most problematic place. Most methods throw an error in case of
failure, which is quite OK. However, to do so they use PyErr_SetString
and PyErr_SetFromErrno family functions, passing the gdbm_errno value
as their argument. This is plain wrong. These functions treat the
errno argument as a value of C "errno" variable. Obviously, gdbm_errno
codes have diffeent meanings, so the resulting diagnostics is misleading
if not downright unusable.

2. Lack of interfaces for database export/import (gdbm_dump and
   gdbm_load functions). This is quite an important aspect, in particular
   for handling database backups.

3. Lack of interface for database recovery (gdbm_recover function).

4. The items() and values() methods are not supported. These should be
   easy to implement using gdbm_firstkey/gdbm_nextkey.