| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,2 @@ | ||
| Using :data:`NotImplemented` in a boolean context has been deprecated. Patch | ||
| contributed by Josh Rosenberg. |
| Back | FazBrowse Home | New Git URL |
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.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityI am not sure that it will be a TypeError. It may be a RuntimeWarning.
The programmer can silence a warning programmatically if it is raised in the code which he cannot change, but he cannot silence a TypeError.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
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.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualitySorry, I didn't see this comment before pushing my changes to datamodel/constants, so they still reference TypeError.
In any event, is there some reason to stop at RuntimeWarning? I thought DeprecationWarning was supposed to give all the "code you cannot change" (third party packages) time to update themselves so nothing is using the error-prone code path by the time it becomes an actual error?
I can change it, but I'd prefer this to be an error eventually; RuntimeWarning is used in a few places, so the guidelines aren't clear, but in most cases it seems to boil down to either a mostly harmless thing where the warning tells you you asked Python to do something nonsensical/suboptimal (e.g. bad buffering configuration), and it chose to ignore you and do something valid/more optimal instead, or in the case of asyncio, a case that is probably an error (failing to await a coroutine), but the problem can't be detected until an unpredictable time after the problem occurred, so raising an exception isn't feasible at that point (the same way exceptions in del are suppressed). In most of these cases, Python can stumble along and ignoring the warning doesn't leave you doing anything wrong, just possibly suboptimal. In almost all cases, if NotImplemented is used in a boolean context, and there is no clearly valid way for Python to handle it (what should have delegated or raised TypeError becomes a return of True or False), thus my preference for (eventually) making it an error.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.