On 9/17/12, Guido van Rossum <gu...@python.org> wrote:
> I don't think I've
> ever had a use case in my own code where I found it particularly
> awkward that I couldn't jump from one except clause to the next;
I have had cases where I wanted to either
(1) Say "oops, not really a match, keep looking at the other except clauses"
The except ... if answers this, but I do think virtual subclasses
would be a better solution. In my case, I would have created a
subclass for file errors that could be fixed automatically.
(2) If there is an exception [of such and such a type] do X, but
sometimes *also* do Y.
The continue could answer this, but I'm not convinced it would smell
any less than the current workarounds.
On 9/16/12, Joshua Landau <joshua.landau...@gmail.com> wrote:
> On 16 September 2012 23:30, Cameron Simpson <c...@zip.com.au> wrote:
>> Having a ridiculous suite of a billion trite
>> subclasses to enumerate the return codes from a lower level (or more
>> "inner") library is just nuts.
If the library created them, it is distinguishing between them --
regardless of whether it distinguishes by name or by number.
> As said above, how is Library.MathError(5) more arbitrary than
> Library.UncalculatableMathError()?
Numbers are more likely to get shifted by accident when someone adds a
new value.
But the point isn't that codes are more arbitrary -- it is that a name
is more helpful when debugging.
> Yes, if you have an incomplete name list you will suffer. But so what? Just
> cover all your bases. If you are wrapping a program from a lower-level
> language, wrap *everything you need*. It's no different to any other aspect
> of wrapping libraries.
And, more to the point, wrap *only* what you need. If you were
providing the sole wrapper for a library, then you might have a fairly
long translation list. But if you're just using the library, only
create virtual subclasses for the conditions that you happen to care
about, and name them based on why they matter.
On 17 September 2012 20:39, Jim Jewett <jimjjew...@gmail.com> wrote:
> On 9/16/12, Joshua Landau <joshua.landau...@gmail.com> wrote:
> > On 16 September 2012 23:30, Cameron Simpson <c...@zip.com.au> wrote:
> > As said above, how is Library.MathError(5) more arbitrary than
> > Library.UncalculatableMathError()?
> Numbers are more likely to get shifted by accident when someone adds a
> new value.
> But the point isn't that codes are more arbitrary -- it is that a name
> is more helpful when debugging.
And I totally agree. My original post was meant to say "how is *
Library.UncalculableMathError()* more arbitrary than *Library.MathError(5)*?"
as a refute to a claim that they are. Thanks for catching that.
> > Yes, if you have an incomplete name list you will suffer. But so what?
> Just
> > cover all your bases. If you are wrapping a program from a lower-level
> > language, wrap *everything you need*. It's no different to any other
> aspect
> > of wrapping libraries.
> And, more to the point, wrap *only* what you need. If you were
> providing the sole wrapper for a library, then you might have a fairly
> long translation list. But if you're just using the library, only
> create virtual subclasses for the conditions that you happen to care
> about, and name them based on why they matter.
> I don't think [the existing syntax] is quite awkward.
Of course it is. It doesn't fit the semantics, and that is why it is
awkward. An exception should be caught by an 'except' clause, not by
a conditional statement. As Antoine's refactoring demonstrates, these
Exceptions that are differentiated by an internal errno are often
conceptually a variety of different exceptions. I agree with the
suggestion that really we should fix up other Exceptions that are
clearly quite heterogeneous by subclassing more precise exceptions
from them.
But this isn't always possible, and of course may not be backward
compatible.
I don't know how to do it Pythonically, but it would be nice if there
were some way to "subclass Exceptions on the fly".
On Tue, Sep 18, 2012 at 11:08 AM, Stephen J. Turnbull
<step...@xemacs.org> wrote:
> I don't know how to do it Pythonically, but it would be nice if there
> were some way to "subclass Exceptions on the fly".
Most likely, this will mean fixing the bug that means the ABC
machinery is currently being ignored by the exception machinery. Then
you can do whatever you want to reshape exception hierarchies.
On Mon, Sep 17, 2012 at 11:55 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Tue, Sep 18, 2012 at 11:08 AM, Stephen J. Turnbull
> <step...@xemacs.org> wrote:
>> I agree with the suggestion that really we should fix up other Exceptions that are clearly quite heterogeneous by subclassing more precise exceptions from them.
>> But this isn't always possible, and of course may not be backward compatible.
If done well, it should be fully backwards compatible. There is not
reason that you cannot keep the errno (or however its named on the
specific exception class) while still subclassing the exception.
You could have issues with pickled exceptions if you add more details
to the exceptions, and it is not forward compatible: newer code that
gets the older form of exceptions is liable to break, without extreme
care to update the exceptions.
>> I don't know how to do it Pythonically, but it would be nice if there
>> were some way to "subclass Exceptions on the fly".
> Most likely, this will mean fixing the bug that means the ABC
> machinery is currently being ignored by the exception machinery. Then
> you can do whatever you want to reshape exception hierarchies.
One trick we've done at work in a few cases is to put a fairly thin
wrapper around the low-level apis that wrap the exceptions into
subclasses. Often, this can be implemented as a simple decorator that
then can be used on a series of functions easily.
> On Mon, Sep 17, 2012 at 11:55 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On Tue, Sep 18, 2012 at 11:08 AM, Stephen J. Turnbull
> > <step...@xemacs.org> wrote:
> >> I agree with the suggestion that really we should fix up other
> >> Exceptions that are clearly quite heterogeneous by subclassing
> >> more precise exceptions from them. But this isn't always
> >> possible, and of course may not be backward compatible.
> > If done well, it should be fully backwards compatible. There is not
> reason that you cannot keep the errno (or however its named on the
> specific exception class) while still subclassing the exception.
Of course that's backward compatible with old code receiving the new
subclassed exceptions. Maybe I misused the term "backward
compatible", but what I meant was that it's likely to be the case that
the person doing the subclassing will unify groups of error codes he
believes unlikely to need distinguishing in Python applications
(vs. more low-level languages). Eg, I don't see more than one hundred
new Exceptions in PEP 3151, but only a handful (about 15).
