Message288615
| Author |
mbussonn |
| Recipients |
brett.cannon, martin.panter, mbussonn, terry.reedy |
| Date |
2017年02月27日.00:18:55 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1488154735.6.0.874647538489.issue26389@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Just came across that with wanting to use print_exception and got the same idea.
It seem like in print_exception, and format_exception, etype is already ignored and `type(value)` is used, so I think we could also "just" also ignore tb (unless set) and use `value.__traceback__`. Leaving the API to function(None, exception)
I don't see any clean way to migrate to a new API (IMHO a forced `exc kwarg` is not discoverable enough vs a (None, e, e.__traceback__)
A possibility, as `etype` is already unused, would be replace it with etype_or_exception, and in case it's a full exception use it as the sole parameter from which type and tb get extracted.
Though that feels weird as well, and the Deprecation Cycles would need to be long.
Already emitting deprecation warnings (that etype is ignored) would be good. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年02月27日 00:18:55 | mbussonn | set | recipients:
+ mbussonn, brett.cannon, terry.reedy, martin.panter |
| 2017年02月27日 00:18:55 | mbussonn | set | messageid: <1488154735.6.0.874647538489.issue26389@psf.upfronthosting.co.za> |
| 2017年02月27日 00:18:55 | mbussonn | link | issue26389 messages |
| 2017年02月27日 00:18:55 | mbussonn | create |
|