Changes by Serhiy Storchaka storch...@gmail.com:
--
type: behavior - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
___
Claudiu.Popa added the comment:
Thanks for the reviews, Serhiy. Here's the new version of the patch.
--
Added file: http://bugs.python.org/file35549/issue18039_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
Changes by Claudiu.Popa pcmantic...@gmail.com:
Added file: http://bugs.python.org/file3/issue18039_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
Roundup Robot added the comment:
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
--
nosy: +python-dev
___
Serhiy Storchaka added the comment:
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.
--
resolution: - fixed
stage: patch review - resolved
R. David Murray added the comment:
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
Serhiy Storchaka added the comment:
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'
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: fixed -
stage: resolved - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
R. David Murray added the comment:
Yeah, hopefully you are right. (I didn't mean to reopen the issue, by the way).
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
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
Claudiu.Popa added the comment:
Thanks, Serhiy. Here's the new version of the patch. Hope that the warning
message is clear enough.
--
Added file: http://bugs.python.org/file35544/issue18039_1.patch
___
Python tracker rep...@bugs.python.org
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
___
Claudiu.Popa added the comment:
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.
--
___
Python tracker
Claudiu.Popa added the comment:
Can anyone review this patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
___
Python-bugs-list
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
versions: +Python 3.5 -Python 3.3
Added file: http://bugs.python.org/file34359/issue18039.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
Changes by Berker Peksag berker.pek...@gmail.com:
--
stage: test needed - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
___
Claudiu.Popa added the comment:
And the patch.
--
keywords: +patch
Added file: http://bugs.python.org/file32455/dbm_dumb_open.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18039
___
Claudiu.Popa added the comment:
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
Berker Peksag added the comment:
I can't reproduce it on Windows 7 with Python 3.3.2.
Attaching my test script.
Here's the output:
C:\Python33python.exe -V
Python 3.3.2
C:\Python33python.exe dbmopen.py
dbm.dumb._Database object at 0x027C15B0
bzdew.dat exists? True
bzdew.dir exists? True
Sashko Kopyl added the comment:
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
New submission from Sashko Kopyl:
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
21 matches
Mail list logo
