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
improved PEP 409 implementation #58341
Comments
It uses a __suppress_context__ attribute rather than the whole Ellipsis mess. |
I don't think it has to be a __special__ attribute. suppress_context would probably be fine. |
__suppress_context__ parallels with __cause__ and __context__. |
Here's a patch which doesn't use the dict. |
I don't consider using Ellipsis as a sentinel value a mess. If you don't like the PEP's solution, take it up with Guido. |
Maybe it's not awful, but why is this not a cleaner solution? |
I find this cleaner than the contrived "Ellipsis as magic value" solution, myself :) |
Because you're breaking the semantics of the "raise X from Y" syntax. That syntax is *just* syntactic sugar for "_exc = X; _exc.__cause__ = Y; raise _exc". Under PEP-409, that remains true. Your patch breaks it. If you want to change the meaning for "raise X from Y", write a new PEP. |
The other problem with the "separate attribute" approach is that it makes the condition for suppressing the context ugly: exc.__suppress_context__ or exc.__cause__ is not None That's hardly cleaner than: exc.__cause__ is not Ellipsis |
I find it cleaner actually, because it states the intent rather than |
Regardless, I'm rejecting this for not complying with the PEP specification (which is quite explicit about the implementation mechanism and the API exposed to Python). If you want to challenge an approved PEP, the correct way to go about it is to write a new PEP. |
FWIW, I agree with Nick: once we go as far as writing PEPs for smaller features, we should keep to the spec as accepted. |
Now with doc changes! |
I don't think it's a good idea for setting one attribute to implicitly set another. |
The alternatives are a backwards compatibility break (i.e. raise exc from other_exc would suppress the context, but exc.__cause__ = other_exc would not) or else that we don't succeed in eliminating the dual use of __cause__ in the display routines. Given that those two problems are the reason I went for the PEP-409 approach in the first place, I'm really only interested in alternative approaches that eliminate them (such as setting the flag automatically whenever __cause__ is set). If you don't like it, then we already have PEP-409's Ellipsis based implementation which meets my criteria. |
Also, ensuring class invariants by setting derived attributes correctly is one of the primary use cases for properties, so objecting to my proposed approach is objecting to a fairly fundamental programming technique. |
Now with implicit setting of __suppress_context__! |
Nick, care to look at the latest patch? |
Reviewed - actual impl looks good to me, couple of comments regarding the docs and tests. |
I'm wondering if allowing printing __context__ and __cause__ is the best idea. Both could have chains and if they do it will be very non-obvious which one came from which. |
With the decision on whether or not to suppress the context moved out to a separate flag, I think we need to allow it. Requiring that the flag be False *and* that the context also be None gets us back to asking the question of why the flag doesn't work when the context is set to a different value. That question was part of the genesis of the Ellipsis-as-sentinel approach in the original 409 implementation. I wouldn't stress too much about the formatting though. Perhaps note in the suppress context docs that the output can get *very* noisy if you turn it off when both cause and context are set, so while it does display all the exception information, the default output isn't going to be very easy to read. |
I have accepted the PEP. bpo-14805 now covers the separate question of allowing both __cause__ and __context__ to be displayed in the same traceback. |
New changeset b0eb7d2a9542 by Benjamin Peterson in branch 'default': |
Thanks for the review/dictating, Nick! |
I hope you're not disappointed when that PEP doesn't show up in the release notes :) |
2012/5/15 Georg Brandl <report@bugs.python.org>:
It gives me more peace of mind than any release note ever could. :) |
Hey, I just saw the release notes for 3.3 and would like a quick confirmation: This is included in 3.3, right? ^^ |
Alright, thought so but wanted a confirmation anyway – thanks a lot :D |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: