Skip to content

Make warnings suppressible through the python warnings module #4999

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
deanm0000 opened this issue Mar 21, 2025 · 1 comment
Open

Make warnings suppressible through the python warnings module #4999

deanm0000 opened this issue Mar 21, 2025 · 1 comment

Comments

@deanm0000
Copy link

fastexcel uses this warn macro here

Over on the python side I want to suppress that through

from warnings import catch_warnings, simplefilter
with catch_warnings():
    simplefilter("ignore")
    read_excel(file_path).load_sheet(0)

but the warning persists. It seems that warnings from rust ought to be caught with the warnings module too.

I was able to do this as a workaround

import logging
fe=logging.getLogger("fastexcel.types.dtype")
fe.disabled=True
from fastexcel import read_excel
read_excel(file_path).load_sheet(0)
@birkenfeld
Copy link
Member

birkenfeld commented Mar 22, 2025

A few steps to unpack here... fastexcel uses the standard Rust log crate, which provides the warn!() macro. It also uses the pyo3-log crate, which redirects Rust log calls to Python logging. That means, it's as if it was implemented in Python and called logging.warning() to emit that message. And just like in Python, these warnings are not related to the warnings emitted and filtered with the warnings module.

An application using libraries that emit logging warnings can call logging.basicConfig (or another config function) at initialization time to generally influence if and where log messages are emitted. Your workaround also works, but it isn't the only way to silence those.

There isn't a bug in PyO3 here - if fastexcel wanted to emit warnings via the warnings module, they should use PyErr::warn instead of log::warn.

However, that API is pretty cumbersome to use, requiring a CStr among others, so I'd say that there is room for improvement, maybe with a py_warn! macro, and we can keep this issue open (with a better title) until that is implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants