-
Notifications
You must be signed in to change notification settings - Fork 223
feat: add from_* style constructor classmethods to StridedMemoryView and deprecate __init__ constructor
#1250
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
base: main
Are you sure you want to change the base?
feat: add from_* style constructor classmethods to StridedMemoryView and deprecate __init__ constructor
#1250
Conversation
…and deprecate `__init__` constructor
|
Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test |
|
/ok to test |
|
| warnings.warn( | ||
| f"Constructing a {clsname} directly from a DLPack-supporting object is deprecated; " | ||
| "Use `StridedMemoryView.from_dlpack` or `StridedMemoryView.from_any_interface` instead." | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this a FutureWarning (https://docs.python.org/3/library/exceptions.html#FutureWarning) or whatever warning type is most appropriate for this deprecation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the one we want is DeprecationWarning. Those are usually off by default, but tools like pytest will collect and display them at the end, so they get shown to developers using the library during their development rather than to "end users". FutureWarning is always on, so is meant for non-developers to see. (Think of like a data processing script that will require the user to change the format of their data in the future...) Fuzzy boundaries between those, of course.
Redo of #1224 without breaking changes.