`BaseException`(`SystemExit`/`KeyboardInterrupt`) is swallowed and converted to a `TypeError` when extracting struct fields

[vpoverennov]

Bug Description

Opening as a bug, but this might be considered a feature request

First - thank you for such a great library
We're using it to speedup some python in a web service running under gunicorn and hit a case where a SystemExit is swallowed and converted to a TypeError if it happened to be raised inside a field extractor in a struct

I believe this code is acting as a bare except: but IMO should be more like except Exception:

pyo3/src/impl_/frompyobject.rs

Lines 45 to 62 in ae64e57

	pub fn extract_struct_field<'a, 'py, T>(
	obj: &'a Bound<'py, PyAny>,
	struct_name: &str,
	field_name: &str,
	) -> PyResult<T>
	where
	T: FromPyObject<'a, 'py>,
	{
	match obj.extract() {
	Ok(value) => Ok(value),
	Err(err) => Err(failed_to_extract_struct_field(
	obj.py(),
	err.into(),
	struct_name,
	field_name,
	)),
	}
	}

This swallows exceptions deriving from BaseException like KeyboardInterrupt (user pressing Ctrl+C) and SystemExit (used by gunicorn to signal worker shutdown - https://github.com/benoitc/gunicorn/blob/a86ea1e4e6c271d1cd1823c7e14490123f9238fe/gunicorn/workers/base.py#L204

Steps to Reproduce

Seems to only happen with nested structs, see full repro here - https://github.com/vpoverennov/pyo3-exceptions-repro/blob/main/src/lib.rs

with a Nested class like this (simulating SystemExit being thrown into an otherwise innocuous getter function)

class Nested:
    @property
    def v(self):
        raise SystemExit(1)

This works fine and SystemExit is raised when calling repro_w

#[derive(FromPyObject, Debug)]
struct Nested {
    v: i32,
}

#[pyfunction]
fn repro_n(b: Nested) -> i32 {
    println!("repro_n: {:?}", b);
    b.v
}

But this converts SystemExit into a TypeError: argument 'a': failed to extract field Wrapper.n

#[derive(FromPyObject, Debug)]
struct Wrapper {
    n: Nested,
}

#[derive(FromPyObject, Debug)]
struct Nested {
    v: i32,
}

#[pyfunction]
fn repro_w(a: Wrapper) -> i32 {
    println!("repro_w: {:?}", a);
    a.n.v
}

Backtrace

Your operating system and version

Windows 10 / MacOS

Your Python version (python --version)

Python 3.10

Your Rust version (rustc --version)

rustc 1.90.0 (1159e78c4 2025-09-14)

Your PyO3 version

0.26.0

How did you install python? Did you use a virtualenv?

not relevant

Additional Info

No response

[davidhewitt]

Thanks for reporting this.

I realise that this raises an interesting question about our error-handling patterns in PyO3 more generally, which I will need to think about.

I think it's well established that bare except in Python is considered bad because it can discard BaseException:

try:
    x = do_thing()
except:  # bad, should be except Exception
    pass

However, the way our Rust error handling in PyO3 is written, it's very easy to accidentally discard BaseException with what looks like idiomatic Rust:

if let Ok(x) = do_thing.call0() {  // bad, discards `BaseException`
    // use x
}

... I can't really see a way around this other than changing the way PyO3 handles Python errors to make the "obvious" thing to do the right thing. Will need discussion and R&D, I think.

[LilyFirefly]

This reminds me of my idea in #4819. We could then write this:

if let Ok(x) = do_thing.call0().ok_or_isinstance_of::<PyException>()? {  // good, only discards instances of `Exception`
    // use x
}

The downsides I see are:

• You have to know to opt-in.
• It's verbose.
• It might be a bit tricky to understand what the method actually does at first.

[LilyFirefly]

Another possibility here would be to make methods like call0 implicitly call .ok_or_isinstance_of::<PyException>(), so the return value would become Result<Result<_, PyErr>, PyErr>:

if let Ok(x) = do_thing.call0()? {  // good, only discards instances of `Exception`
    // use x
}

This would be a very big compatibility break though. And really painful when we just want to bubble all exceptions up.

[davidhewitt]

I think what you suggest is probably the sort of thing we need, though I'd agree I'd prefer less verbosity.

And really painful when we just want to bubble all exceptions up.

My gut feeling is that most callsites just want to bubble all exceptions up, so the default of ? should ideally still work and also not even bother checking whether the exception is an Exception or BaseExeception.

I think we want to avoid users discarding errors offhand, so e.g. .ok() on a Result type is an instant problem. We could prevent this by making PyErr::drop panic and forcing users to handle them properly, but that creates a runtime pain.

I fear the combination of the above two desires means that really to have a workable solution here we'll need stable Try so that we can have a custom result-like type.

We could then have something like

do_thing
    .call0()
    .except(|e| {  // I guess this is very similar to `Result::or_else`
        if let Some(type_error) = e.as::<PyTypeError>() {
            // exc is cast as `PyException`
            Ok(())
        } else if let Some(value_errors) = e.is_group::<PyValueError>() {
            // exc is list of value errors, similar to `except* ValueError
            Ok(())
        } else {
            Err(e)
        }
    })?;

... maybe the closer we can make it to Python exception handling the better? Not sure.

Alternatively, given try blocks are a nightly thing, maybe we could be experimenting with a py_try! macro which behaves similarly:

let x = py_try! {
    do_thing.call0()
except Exception:
    pass  // I guess a macro could make `pass` legal syntax, or we could just have `Ok(())`
}?;

The downside of such a macro would be that it would not be sensitive to whitespace indentation, unlike Python.

[Cheukting]

In my opinion, I think Python try except only works with the whitespace indentation, I like @LilyFirefly 's suggestion better. Or make the py_try! macro works like the try block...