feat(python): use returncode for python exec

[ianhi]

Formats and displays any exceptions when returncode is not 0.

This is helpful if you want to demonstrate code that you expect to raise an error. Doubly so when you are running wiht mkdocs build --strict

Example rendering in mkdocs-material:

```python exec="on" source="above" returncode="1" result="python"
print("Hello Markdown!")
raise ValueError
```

[ianhi]

May also make sense to use redirect_stdout and redirect_stderr (https://docs.python.org/3/library/contextlib.html#contextlib.redirect_stdout) instead of patching the print function. In case there are expected outputs that never get printed

[pawamoy]

Hey @ianhi, thanks a lot for the PR! I like it. Could you update the docs to add a section similar to the Shell one, into the Python page? And update the main Usage page to reference both 🙂

[pawamoy]

Suggested change

	if returncode not in [None, 0]:
	if returncode not in (None, 0):

[ianhi]

After sleeping on it I've realized it might be nice to be able to specify the exception type, rather than returncode. How do you feel about adding a new field like exception="ValueError" then making sure to match that, and not having returncode do anything for python?

[ianhi]

Ok, latest push implements that idea. I think I have one more section of docs to update but curious if you prefer this approach. Switching to exception matching for python/pycon (but not pyodide) and returncode just for shell

[pawamoy]

I have thought about it and I think I'd prefer we stay with returncode for now, because asserting exception types is under-specified here. What if users write exception="some_package.SomeException"? We'd have to actually import the object dynamically to compare it against the caught exception (as asserting the type as you've done it here, using string in message, wouldn't work, and is not robust enough IMO). Users could also want to use the local scope, i.e. exception="SomeException" because SomeException was imported in the executed code block. Also, they might want to assert more than the type, for example the exit code in SystemExit, or the actual message of the exception, etc.. This brings a lot of complexity that we'd have to discuss in an issue first 🙂