On Wed, Oct 30, 2019 at 11:29:55PM -0700, Ben Rudiak-Gould wrote:
On Sun, Oct 27, 2019 at 4:17 PM Andrew Barnert
wrote: On Oct 27, 2019, at 15:07, Ben Rudiak-Gould
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.
I disagree. I think it's a pretty small breaking change, and precisely the sort of thing that __future__ was designed to handle. We could enable it on a module-by-module basis, and wouldn't need to rush to make it mandatory. The print thing in Python 3 was the most obvious and visible change, but the actual change from the perspective of the average coder was quite small. It was easily handled by a future import, and by 2to3 fixers. (Apart from one or two obscure corner cases involving softspace, if I remember correctly.) The raise statement is quite simple: raise [expression [from expression]] Syntactically, we could replace it with a function call with three cases: raise() raise(expression) raise(expression, from=expression) except we can't use "from" as the keyword name, we would have to use something else like "cause=expression" or similar. The only complexity I can think of is that tracebacks will have an extra entry, unless the traceback machinery knows enough to suppress it. I can't think of any situation where raise needs to be a statement.
Writing it in C would fix that,
That might work too :-) and if raise became a builtin function, that would have to happen regardless. -- Steven