On Oct 31, 2019, at 07:29, Ben Rudiak-Gould <benrud...@gmail.com> wrote: > >> On Sun, Oct 27, 2019 at 4:17 PM Andrew Barnert <abarn...@yahoo.com> wrote: >>> On Oct 27, 2019, at 15:07, Ben Rudiak-Gould <benrud...@gmail.com> wrote: >>> from __future__ import raise_function >> That’s a pretty big breaking change. > > I agree, it's a bad idea. It'd have to be Python 4, like > print_function was Python 3. > >> def throw(e): raise e > > The problem with this is that it adds an extra line to the traceback, > so you have to choose between the convenience of using it and the > convenience of more readable tracebacks. > > Writing it in C would fix that, but it's pretty complicated (I think I > could copy the logic from do_raise in ceval.c, but I'm not completely > sure, and it's almost 100 lines long), and of course not portable. I > wouldn't mind having a sys.throw or something that's guaranteed to do > it correctly.
Is a lot simpler than that. But you shouldn’t have to do it nonetheless. You can also hack up a solution in pure Python by manipulating the traceback manually. The quick&dirty way to do this using the frame objects is nonportable, but it is doable portably, it just might be a lot more of a pain. In fact, I think you can borrow and simplify code from importlib to do it. When the import machinery was rewritten from mostly C to pure Python around 3.4, they had to come up with a workaround to make ImportError tracebacks still look like they used to instead of including an extra 6 functions in the middle that nobody cares about except people working on the import system or an import hook. IIRC, what they do is call a bracketing function on entering the import machinery and then another one on calling back out, and then the top level functions have code that edits tracebacks that pass through by removing entries between those two brackets. > Actually, it'd be nice to have some general way to write trivial > wrappers in Python without uglifying tracebacks, but that's a > different discussion. If you have an idea for a solution for that, it’s probably worth starting that discussion, because that would be worth having. It’s not a super-common need, but it does come up, and I think people usually solve it nonportably when it does. I know I’ve dealt with a couple third-party libraries (over the decades) that had to be patched to work in a non-CPython interpreter because of it. If everyone is doing it wrong because it’s too hard to do it right, it seems like it’s worth making it easier to do it right. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2ERGJFMAVNTM4OMVBOLEJ4CCB7TALPOB/ Code of Conduct: http://python.org/psf/codeofconduct/
