8000 PEP 554: Address feedback. by ericsnowcurrently · Pull Request #426 · python/peps · GitHub
[go: up one dir, main page]
Skip to content

PEP 554: Address feedback. #426

New issue 8000

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 26 commits into from
Sep 22, 2017
Merged

PEP 554: Address feedback. #426

Changes from 1 commit
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
1bfc96e
Update the post history.
ericsnowcurrently Sep 15, 2017
4fbb993
Add a link about the bug rate.
ericsnowcurrently Sep 16, 2017
7a6e00f
Add a note about JEP.
ericsnowcurrently Sep 16, 2017
84eec8f
Clarify the semantics of closing channels.
ericsnowcurrently Sep 22, 2017
1aff1f3
Add an extra solution to the problem of resetting __main__.
ericsnowcurrently Sep 22, 2017
1dd0050
Add a note about async.
ericsnowcurrently Sep 22, 2017
66d5768
Add an open question about the main thread.
ericsnowcurrently Sep 22, 2017
42d44d9
Clarify about "execution namespace".
ericsnowcurrently Sep 22, 2017
4312d64
Raise ValueError for unsupported values.
ericsnowcurrently Sep 22, 2017
6363e64
Clarify about "no longer used".
ericsnowcurrently Sep 22, 2017
859fb01
Drop RecvChannel.__next__().
ericsnowcurrently Sep 22, 2017
de9cc53
Add a note about context managers.
ericsnowcurrently Sep 22, 2017
7990474
Fix a typo.
ericsnowcurrently Sep 22, 2017
8d9d4eb
Fix the note about timeouts.
ericsnowcurrently Sep 22, 2017
e46790a
Fix a typo.
ericsnowcurrently Sep 22, 2017
efd0d9a
Clarify about resetting __main__.
ericsnowcurrently Sep 22, 2017
ac2f832
Add a note about pipes and queues.
ericsnowcurrently Sep 22, 2017
5d73daa
Quote Nick about isolation.
ericsnowcurrently Sep 22, 2017
2d47882
Note possible solutions to exception leakage.
ericsnowcurrently Sep 22, 2017
7c18b97
Use textwrap.dedent() in examples.
ericsnowcurrently Sep 22, 2017
a52e367
Add a note about distinguishing errors out of run().
ericsnowcurrently Sep 22, 2017
f4fe10f
Add more options for not leaking exceptions.
ericsnowcurrently Sep 22, 2017
3fd9f9f
Add a note about explicitly passing channels to run().
ericsnowcurrently Sep 22, 2017
d3c1cf7
Add more notes about the "main" thread.
ericsnowcurrently Sep 22, 2017
150ac9e
Fill in a little info about other implementations.
ericsnowcurrently Sep 22, 2017
5197939
Do not mention being inspired by the threading module.
ericsnowcurrently Sep 22, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add a note about distinguishing errors out of run().
  • Loading branch information
@ericsnowcurrently
ericsnowcurrently committed Sep 22, 2017
commit a52e367a74b7e48e10fa84c068a888bb056e9c59
15 changes: 15 additions & 0 deletions pep-0554.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -877,6 +877,21 @@ reasonable. The could be trivially implemented as wrappers around
channels. Alternatively they could be implemented for efficiency at the
same low level as channels.

interpreters.RunFailedError
---------------------------

As currently proposed, ``Interpreter.run()`` offers you no way to
distinguish an error coming from sub-interpreter from any other
error in the current interpreter. Your only option would be to
explicitly wrap your ``run()`` call in a ``try: ... except Exception:``.

If this is a problem in practice then would could add something like
``interpreters.RunFailedError`` and raise that in ``run()``, chaining
the actual error.

Of course, this depends on how we resolve `Leaking exceptions across
interpreters`_.


Rejected Ideas
==============
Expand Down
0