On 12Apr2015 07:52, Chris Angelico <ros...@gmail.com> wrote:
On Sun, Apr 12, 2015 at 7:37 AM, Cameron Simpson <c...@zip.com.au> wrote:
On 11Apr2015 21:21, Chris Angelico <ros...@gmail.com> wrote:
But I agree, it would be very nice if Python 3 could have abolished
the truly confusing part of this, where "except:" catches everything.
Forcing people to spell it "except BaseException:" would fix all of
this. How hard is it to deprecate and then remove that, same as string
exceptions were removed?
I guess I'll go over there to oppose it then.
Why? It makes it harder to write portable python 2/3 code and does not add
any semantic advantage.
Unless there's a common root exception class in Python 2, which I believe
there isn't, you can't catch all exceptions in python 2 without the
"except:" syntax. Which means the _only_ way to have some code in both 2
and 3 that does it requires 2 codebases.
As one who tries to have his code run in both 2 (usually recent 2, like
2.6/2.7) and 3, this change would cause a signification breakage for me
without bringing any semantic benefits.
Can you give an example of a place where in Py2 you absolutely have to
catch everything, and don't have control over the code, *and* are
trying to do a one-codebase routine with Py3 compatibility? If you're
trying for 2/3 compatibility, you'll need to have all your exceptions
derive from BaseException anyway.
I don't make many personal exception classes, tending to reuse stdlib ones. I'm
sure I have a few.
But regarding codebase:
[hg/css]fleet*> g except: **/*.py
lib/python/cs/app/pilfer.py:664: except:
lib/python/cs/asynchron.py:145: except:
lib/python/cs/db.py:184: except:
lib/python/cs/excutils.py:34: except:
lib/python/cs/fileutils.py:69: except:
lib/python/cs/idset.py:46: except:
lib/python/cs/later.py:156: except:
lib/python/cs/mailutils.py:274: except:
lib/python/cs/nodedb/tokcab.py:57: except:
lib/python/cs/queues.py:441: except:
lib/python/cs/queues.py:458: except:
lib/python/cs/threads.py:131: except:
Catching all exceptions isn't terribly common, _except_ in service routines
that wrap "unknown" operations. Classic example from my Asynchron class:
def call(self, func, *a, **kw):
''' Have the Asynchron call `func(*a,**kw)` and store its values as
self.result.
If `func` raises an exception, store it as self.exc_info.
'''
try:
r = func(*a, **kw)
except:
self.exc_info = sys.exc_info
else:
self.result = r
All sorts of things like thread pools and other "worker" functions, and
run-forever daemons like mail filers that can have arbitrary exceptions occur
in (partly) third party code eg from config files; you need to catch any
unknown exception and fail the specific action, but continue the main daemon
operation.
And since I use this code in Python 2, and since not all exceptions are
BaseException subclasses, I need the bare syntax.
Also, IMO, a bare "except:" syntax is _far_ more pleasing to the eye than
"except magic_exception_name_that+gets_everything:". Also, I wish
"BaseException" were just spelled "Exception", if it has to be used.
At very worst, it could be turned into a compat-only syntax feature,
like the u"spam" noise prefix on Unicode strings - serving absolutely
no purpose in Py3 code, and ideally, able to be removed at some point
post-2020.
I'm -0.1 on the idea myself. I consider "except:" succinct and evocative, and
prefer it to "except BaseException:".
Cheers,
Cameron Simpson <c...@zip.com.au>
On a videophone, the whole world can see you fart. - Charlie Stross
--
https://mail.python.org/mailman/listinfo/python-list
