Éric Araujo mer...@netwok.org added the comment:
Reading PEP 0249 I can see Gerhard is correct, this patch would violate the
PEP.
Me too.
I think that the PEP is slightly flawed in that users are encouraged to raise
exceptions
called Warning. IMHO a Warning is never an exceptional
Nick Craig-Wood n...@craig-wood.com added the comment:
I think the fact that sqlite may not be using the warnings properly is
independent of this problem. Warnings should be filterable, but if sqlite
isn't notifying them properly - that would be a different bug.
BTW I came across this
Éric Araujo mer...@netwok.org added the comment:
I agree with Antoine. You say you want to filter warnings, but you can’t since
they are not warnings.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9510
Gerhard Häring g...@ghaering.de added the comment:
PEP 0249 says that the module's Warning class must be a subclass of
StandardError. So I reject your proposed change.
There are only two cases where pysqlite raises Warning, and these could be
changed to ProgrammerError anyway.
--
Nick Craig-Wood n...@craig-wood.com added the comment:
Reading PEP 0249 I can see Gerhard is correct, this patch would violate the PEP.
I think that the PEP is slightly flawed in that users are encouraged to raise
exceptions called Warning. IMHO a Warning is never an exceptional condition
New submission from Nick Craig-Wood n...@craig-wood.com:
sqlite3.Warning isnt a subclass of exceptions.Warning
This causes this problem when trying to filter warnings
import sqlite3 as DB
from warnings import filterwarnings
filterwarnings(always, category=DB.Warning)
Traceback (most recent
Nick Craig-Wood n...@craig-wood.com added the comment:
I've attached a patch to fix the issue along with a revised test.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9510
___
Éric Araujo mer...@netwok.org added the comment:
I agree this is a bug, and the patch looks good. This breaks compatibility
though, so I’m not sure it can make it before 3.2 or 3.3.
--
nosy: +merwok
stage: - commit review
versions: +Python 3.2 -Python 2.7
Antoine Pitrou pit...@free.fr added the comment:
I don't really think it breaks compatibility.
The patch is bad, though. The exceptions module doesn't exist anymore in 3.x,
the Warning class should be referenced directly instead.
--
nosy: +ghaering, pitrou
stage: commit review - patch
Éric Araujo mer...@netwok.org added the comment:
I mean that sqlite3.Warning used to be a subclass of StandardError, and there
may be code relying on that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9510
Antoine Pitrou pit...@free.fr added the comment:
Ah, I see. Well I don't think we can change inheritance in bugfix branches
anyway.
In 3.x, though, StandardError has disappeared and sqlite3.Warning inherits
directly from Exception:
import sqlite3
sqlite3.Warning.__bases__
(class
Éric Araujo mer...@netwok.org added the comment:
Warning is a subclass of Exception, so perfect.
Please add 2.7 and 3.1 if you agree this bugfix should go there too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9510
Nick Craig-Wood n...@craig-wood.com added the comment:
I re-worked the patch for python 3.x (py3k branch) - the other was for 2.x
(trunk)
Basically the same patch and fixes the issue according to my testing
--
Added file: http://bugs.python.org/file18386/sqlite3-warning-fix-py3k.patch
Éric Araujo mer...@netwok.org added the comment:
Nitpick: s/built in/built-in/ (don’t update your patch for that, the person who
will commit can do it)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9510
Antoine Pitrou pit...@free.fr added the comment:
On the other hand, the sqlite3 source code uses PyErr_Set*() rather than
PyErr_Warn*(), so there's any point in trying to filter the warnings out (it
won't work).
Looking at the kind of problems that it is meant to reflect, Warning is
actually
15 matches
Mail list logo
