On Oct 31, 2019, at 13:56, Steven D'Aprano <st...@pearwood.info> wrote: > > I disagree. I think it's a pretty small breaking change,
From my test earlier on the thread, using a function to raise makes a function that does nothing but raise and handle an exception take more than twice as long. Which implies that the actual raise part (not counting the outer function call, handling the exception, and returning) is far more than twice as long. This wasn’t an issue with print. For one thing, print is almost always doing other slow stuff (calling str on everything, encoding the resulting string, and then writing it to a file, which typically involves a syscall, and on Windows waiting milliseconds for cmd.exe, and in 3.0 when print_function was added the horribly slow file object implementation), so the extra function overhead was a small fraction of a percent, while here it’s well over 100%. Also, there are many places in the Python data model where you have to raise an exception, such as StopIteration; there are no places where you need to print. And if you need output and print is too slow, you can always go below; there’s no way to raise an exception without raise. And what’s the advantage? If we need raise inside an expression without extra overhead, this doesn’t solve the problem; we’d need a raise expression (similar to the yield expression), not a raise function. Which has the advantage of not breaking any existing code (except for code that deals with AST nodes or tokens). If we don’t care about the overhead, there is no problem to solve; you can already get this behavior with a one-liner. If that’s still too inconvenient or undiscoverable, we can add the one-liner to builtins without removing the statement at the same time. So, what’s the benefit of removing the statement? _______________________________________________ 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/GHSRCJQ5HTJ447SOUO35R5ABDJDBM6HZ/ Code of Conduct: http://python.org/psf/codeofconduct/
