Explanation
According to
|
def logger_warning(msg: str, src: str) -> None: |
|
""" |
|
Use this instead of logger.warning directly. |
|
|
|
That allows people to overwrite it more easily. |
|
|
|
## Exception, warnings.warn, logger_warning |
|
- Exceptions should be used if the user should write code that deals with |
|
an error case, e.g. the PDF being completely broken. |
|
- warnings.warn should be used if the user needs to fix their code, e.g. |
|
DeprecationWarnings |
|
- logger_warning should be used if the user needs to know that an issue was |
|
handled by pypdf, e.g. a non-compliant PDF being read in a way that |
|
pypdf could apply a robustness fix to still read it. This applies mainly |
|
to strict=False mode. |
|
""" |
|
logging.getLogger(src).warning(msg) |
logger_warning is advertised to allow overwriting, but doing so proves to be more complicated than expected.
There basically are two reasons for this:
- The implementation is located at
pypdf._utils.logger_warning, which usually marks an internal implementation and thus I would not assume this to be future-proof.
- The method usually is imported directly, as can be seen in
for example. This requires patching each import separately.
Explanation
According to
pypdf/pypdf/_utils.py
Lines 433 to 449 in 11ee648
logger_warningis advertised to allow overwriting, but doing so proves to be more complicated than expected.There basically are two reasons for this:
pypdf._utils.logger_warning, which usually marks an internal implementation and thus I would not assume this to be future-proof.pypdf/pypdf/filters.py
Line 46 in 11ee648