Skip to content
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

send errors in __releasebuffer__ to sys.unraisablehook #2886

Merged
merged 1 commit into from
Jan 19, 2023

Conversation

davidhewitt
Copy link
Member

I noticed that in the __releasebuffer__ implementation we currently diverge from documentation by allowing -> PyResult<()> return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set

After some deliberation I decided to allow -> PyResult<()> returns because:

  • it keeps the macro implementation and usage simpler
  • errors might be produced by the __releasebuffer__ internals anyway (e.g. due to PyCell locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to sys.unraisablehook, and updates the documentation to be clearer on the allowed behaviour.

src/impl_/pyclass.rs Outdated Show resolved Hide resolved
@davidhewitt
Copy link
Member Author

Thanks as always for the thorough review! I've pushed a commit which should address all of those points and hopefully pass CI.

@davidhewitt
Copy link
Member Author

bors r=adamreichold

bors bot added a commit that referenced this pull request Jan 19, 2023
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=adamreichold a=davidhewitt

I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

```
ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```

After some deliberation I decided to allow `-> PyResult<()>` returns because:
 - it keeps the macro implementation and usage simpler
 - errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.

Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Canceled.

@davidhewitt
Copy link
Member Author

bors r+

bors bot added a commit that referenced this pull request Jan 19, 2023
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=davidhewitt a=davidhewitt

I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

```
ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```

After some deliberation I decided to allow `-> PyResult<()>` returns because:
 - it keeps the macro implementation and usage simpler
 - errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.

Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Canceled.

@davidhewitt
Copy link
Member Author

bors r=adamreichold

bors bot added a commit that referenced this pull request Jan 19, 2023
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=adamreichold a=davidhewitt

I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.

e.g. without the other changes in this PR, the new test case would crash with the following message:

```
ValueError: oh dear

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```

After some deliberation I decided to allow `-> PyResult<()>` returns because:
 - it keeps the macro implementation and usage simpler
 - errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)

As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.

Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Build failed:

@davidhewitt
Copy link
Member Author

bors r=adamreichold

@bors
Copy link
Contributor

bors bot commented Jan 19, 2023

Build succeeded:

  • conclusion

@bors bors bot merged commit 0c9078a into PyO3:main Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants