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 <[email protected]> wrote:
> > On Oct 27, 2019, at 15:07, Ben Rudiak-Gould <[email protected]> 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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/PJHTHLZVVF2SCXCGYV6FKA2DRO7XOFAC/
Code of Conduct: http://python.org/psf/codeofconduct/
