On Wed, 2020-07-22 at 17:35 -0600, Aaron Meurer wrote: > > About your warnings, do you have a nice way to do that? The > > mechanism > > for warnings does not really give a good way to catch that a > > warning > > was raised and then turn it into an error. Unless someone > > contributes > > a slick way to do it, I am not sure the complexity pays off. > > I don't really know how flags and options and such work in NumPy, but > I would imagine something like > > if flags['post-deprecation'] = True: # Either a single flag for all > deprecations or a per-deprecation flag > raise IndexError(...) > else: > warnings.warn(...) >
We have never done global flags for these things much in NumPy, I don't know of precedence in other packages, possibly aside future imports, but I am not even sure they have been used in this way. > I don't know if the fact that the code that does this is in C > complicates things. > > In other words, something that works kind of like __future__ flags > for > upgrading the behavior to post-deprecation. > > > IIRC, I added the note about raising the warning, because in this > > particular case the deprecation warning (turned into an error) > > happens > > to be chained due to implementation details. (so you do see the > > "original" error printed out). > > Yes, it's nice that you can see it. But for my use case, I want to be > able to "except IndexError". Basically, for ndindex, I test against > NumPy to make sure the semantics are identical, and that includes > making sure identical exceptions are raised. I also want to make it > so > that the ndindex semantics always follow post-deprecation behavior > for > any NumPy deprecations, since that leads to a cleaner API. But that > means that my test code has to do fancy shenanigans to catch these > deprecation warnings and treat them like the right errors. > > But even as a general principle, I think for any deprecation warning, > users should be able to update their code in such a way that the > current version doesn't give the warning and also it will continue to For FutureWarnings, I will always try very hard to give an option to opt-in to new behaviour or old behaviour – ideally with code compatible also with earlier NumPy versions. Here, for a DeprecationWarning that has obviously no "alternative", I cannot think of any precedence in any other package or Python itself doing such a dance. And it is extremely fringe (you only need it because you are testing another package against numpy behaviour!). So I am happy to merge it if its proposed (maybe its easier for you to add this to NumPy then work around it in your tests), but I am honestly concerned that proposing this as a general principle is far more churn then worth the trouble. At least unless there is some consensus (and probably precendence in the scientific python ecosystem or python itself). Cheers, Sebastian > work and be idiomatic for future versions. For simple deprecations > where you remove a function x(), this is often as simple as telling > people to replace x() with y(). But these deprecations aren't so > simple, because the indexing itself is valid and will stay valid, > it's > just the behavior that will change. If there's no way to do this, > then > a deprecation warning serves little purpose because users who see the > warning won't be able to do anything about it until things actually > change. There would be little difference from just changing things > outright. For the list as tuple indexing thing, you can already kind > of do this by making sure your fancy indices are always arrays. For > the out of bounds one, it's a little harder. I guess for most > use-cases, you aren't actually checking for IndexErrors, and the > thing > that will become an error usually indicates a bug in user code, so > maybe it isn't a huge deal (I admit my use-cases aren't typical). > > Aaron Meurer > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion