A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-May/053625.html below:

[Python-Dev] Merging PEP 310 and PEP 340-redux?

[Python-Dev] Merging PEP 310 and PEP 340-redux? [Python-Dev] Merging PEP 310 and PEP 340-redux?Paul Moore p.f.moore at gmail.com
Wed May 11 14:36:15 CEST 2005
On 5/11/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I've posted draft 1.4 of my PEP 310/PEP 340 merger PEP (PEP 650, maybe?):
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html

I've been skipping the discussion, but this is starting to look pretty
good. I'll give it a proper read soon. However, one thing immediately
struck me: if __exit__ gets an exception and does not re-raise it, it
is silently ignored. This seems like a bad idea - the usual "errors
should not pass silently" applies. I can very easily imagine statement
templates accidentally eating KeyboardInterrupt or SystemExit
exceptions.

At the very least, there should be a section in "rejected
alternatives" explaining why it is not appropriate to force reraising
of exceptions unless explicit action is taken. There could be good
reasons (as I say, I haven't followed the discussion) but they should
be recorded. And if there aren't any good reasons, this behaviour
should probably be changed.

Paul.

PS Apologies if I missed the discussion of this in the PEP - as I say,
I've only skimmed it so far.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4