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