Skip to content

Conversation

@robsdedude
Copy link
Member

Using warnings.catch_warning for suppressing warnings when using APIs internally that are preview/experimental/deprecated is a bad idea because the warnings module stores the configuration globally per module. This is not thread-safe. Therefore, the code was restructured to not rely of the warnings module to suppress those warnings. Instead, warning-free internal APIs are being used.

Backport of: #961

Using `warnings.catch_warning` for suppressing warnings when using APIs
internally that are preview/experimental/deprecated is a bad idea because the
`warnings` module stores the configuration globally per module. This is not
thread-safe. Therefore, the code was restructured to not rely of the `warnings`
module to suppress those warnings. Instead, warning-free internal APIs are being
used.
Copy link
Contributor

@bigmontz bigmontz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️

@robsdedude robsdedude merged commit 5da08ae into neo4j:4.4 Apr 12, 2024
@robsdedude robsdedude deleted the fix/warning-global-state-4.4 branch April 12, 2024 10:16
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