overhaul warning use so that we can parameterize warnings
Issue #3178
resolved
took 5 minutes to actually look at the warnings registry. Let's change our long standing approach of parameterized warnings, e.g. for unicode and other things where it really helps to see the value, and just go for no registry for these. We will augment warn() to accept *args that can be interpolated; if these are present, we skip the registry.
Also, if we just re-implement warnings.warn(), we can do the stack frame stuff they are doing there anyway and express it in terms of the application outside of sqlalchemy without guessing on stacklevel.
this applies to #2992 as well as we want to warn for textual strings and I'd really like to put the string in the warning.
Comments (3)
-
reporter -
reporter - changed status to resolved
- A new style of warning can be emitted which will "filter" up to
N occurrences of a parameterized string. This allows parameterized
warnings that can refer to their arguments to be delivered a fixed
number of times until allowing Python warning filters to squelch them,
and prevents memory from growing unbounded within Python's
warning registries.
fixes
#3178
→ <<cset 3c60d3b1ca49>>
-
reporter - fix a regression from ref
#3178, where dialects that don't actually support sane multi rowcount (e.g. pyodbc) would fail on multirow update. add a test that mocks this breakage into plain dialects
→ <<cset f49c367ef712>>
- fix a regression from ref
- Log in to comment
looking to do it like this, will commit soon
if someone uses the "once" filter, there's a global dictionary out of our reach. so this is the only way to go.
there's not really any performant solution to the stack trace part of this, just going to leave that.