Issue 18039: dbm.open(..., flag="n") does not work and does not give a warning

I use Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32.

dbm.open(..., flag="n") is supposed to "Always create a new, empty database, open for reading and writing".
In Windows case it does not. So I cannot empty a dbm database when I need it.

http://docs.python.org/3/library/dbm.html#module-dbm.dumb
Here it is written:
"The optional flag argument is currently ignored; the database is always opened for update, and will be created if it does not exist."

If it is ignored, there should be at least a warning. How am I supposed to now that this is a known bug?

I can't reproduce it on Windows 7 with Python 3.3.2.

Attaching my test script.

Here's the output:

C:\Python33>python.exe -V
Python 3.3.2

C:\Python33>python.exe dbmopen.py
<dbm.dumb._Database object at 0x027C15B0>
bzdew.dat exists? True
bzdew.dir exists? True
b'hello' b'there'

Could you run it and paste here the output?

Here is the output.


*** Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32. ***
*** Remote Python engine  is active ***
>>> 
*** Remote Interpreter Reinitialized  ***
>>> 
<dbm.dumb._Database object at 0x02B95210>
yoqaA.dat exists? True
yoqaA.dir exists? True
b'hello' b'there'
>>> 


I would like to focus your attention, that flag "n" creates a database, but does not overwrite it once it is created. So in Windows case there is no difference between "c" and "n" flag.
You can have a look at this link where it was originally discussed.
http://stackoverflow.com/questions/16647131/how-to-empty-dbm-file-in-python-efficiently

Here's a patch which adds support for the `n` value of the flag. It makes the dbm consistent across implementations and it's thus more reliable.
Also, attached a script which replicates the problem for Windows (where dbm.dumb is used).


My output (after a couple of runs):


D:\Projects\snippets\DBM>py -3 a.py u7
test
[b'u3', b'u2', b'u5', b'u4', b'u7', b'u6']
test.dat exists? True
test.dir exists? True
b'u3' b'there'
b'u2' b'there'
b'u5' b'there'
b'u4' b'there'
b'u7' b'there'
b'u6' b'there'

And the patch.

Can anyone review this patch?

Serhiy, could you please have a look at this patch? Given the fact that you committed my last dbm patch, I hope you have a couple of minutes to have a look at this one as well.

With this patch 2 of 4 modes ('c' and 'n') work as for other dbm modules. So it would be better to document that 'r' and 'w' work nonstandard, than document that 'n' is not ignored.

And while you are here, may be add a warning in 'r' and 'w' mode when the file does not exist?

Thanks, Serhiy. Here's the new version of the patch. Hope that the warning message is clear enough.

Thanks for the reviews, Serhiy. Here's the new version of the patch.

New changeset 3f944f44ee41 by Serhiy Storchaka in branch 'default':
Issue #18039: dbm.dump.open() now always creates a new database when the
http://hg.python.org/cpython/rev/3f944f44ee41

Committed original Claudiu's patch (issue18039.patch) with minor changes. For warnings I opened separate issue (issue21708) because patch becomes too large.

Thank you Claudiu for your patch.

Isn't this change going to cause unexpected data loss for (possibly mythical) people depending on the existing behavior?  At an absolute minimum it needs an entry in the What's New porting section, but I'm wondering if a deprecation period is more appropriate.

I think the chance of this is pretty small. I can imagine that some people use default, 'r' or 'w' mode unintentionally, and all works for them even when database is missed (for example our tests do this). But it is very unlikely that someone use the 'n' mode and expect that database will be not cleaned.

Yeah, hopefully you are right.  (I didn't mean to reopen the issue, by the way).

stage: patch review -> resolved

nosy: + r.david.murray
messages: + msg220188

resolution: fixed -> (no value)
stage: resolved -> patch review

stage: patch review -> resolved

messages: + msg220153

messages: + msg220113

nosy: + berker.peksag
messages: + msg190401

stage: test needed