-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Introduction of ExperimentalWarning #11326
Conversation
One or more of the the following people are requested to review this:
|
c586aa9
to
a66d35b
Compare
Pull Request Test Coverage Report for Build 7724747077Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
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.
Thanks @1ucian0 I like new warning class, since general UserWarning
is hard to search for and could be left unintentionally. I guess it's also convenient to have some unit test util or base class that automatically ignore the warning because it's bit cumbersome to write with self.assertWarns(ExperimentalQiskitAPI):
for every test case for the new feature.
qiskit/utils/experimental.py
Outdated
def __init__(self, api_name): | ||
self.api_name = api_name | ||
super().__init__( | ||
f"Calling {self.api_name} is experimental and it might be changed or removed at " |
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 emit this warning in a constructor of some class (if the entire class is experimental)? Saying Calling MyNewClass.__init__() is experimental...
seems bit awkward.
I'd forgotten that this existed, and I've made #11522 that similarly adds a I think #11522 is close to merge - maybe best to retarget this PR on top of that once it's in, and use the to-be-existing |
Luciano: are you interested in getting this rebased over main and getting it in? I'd suggest putting I'm thinking that a sensible story for integrating the new OQ3 importer could be to expose the native one as |
In the interests of moving this PR forwards, I've switched out the previous implementation for the version that I had previously included in #11584, which builds on top of the I've not included a particular error message in the warning - I'm not fully convinced there's value added by it, when the warning class name and documentation of the class describe it. I've also not included any decorators to apply it - imo it should be very infrequently used and only in very specialised situations, where it'll be most appropriate for people to write their own specific message explaining the situation. Let me know what you think on it - I've left the previous commit as an object in this PR, even though I reverted it with a5a5605, so the PR can easily be rolled back to it if necessary. |
Co-authored-by: Luciano Bello <bel@zurich.ibm.com>
The stability policy introduces the support for experimental APIs. The documentation says that an experimental API should have a warning in the documentation and raise a UserWarning. Here is a suggestion for that second part. For the first one, decorators like in the deprecation case are probably prefer.