Steve Jorgensen writes:
> Paul Moore wrote:
> > The built in exceptions are ones that are raised by the core interpreter.
> OK, but by that logic, why do we have standard exceptions like
> `ValueError` when we could define custom exceptions for the cases
> where that should be raised?
I
>
> It depends on context whether it makes sense to define a custom exception,
> and I agree that I frequently should define a custom exception. In that
> case though, it would still be nice to have an appropriate generic
> exception for that to inherit from, just as I would inherit from
>
On Fri, Sep 02, 2022 at 06:49:37AM +0800, Matthias Görgens wrote:
> >
> > If the target of the call isn't in an appropriate state, isn't that a
> > bug in the constructor that it allows you to construct objects that are
> > in an invalid state?
> >
> > You should fix the object so that it is never
On Fri, Sep 02, 2022 at 12:53:47AM -, Steve Jorgensen wrote:
> I didn't say that I was talking about a file. In fact, today, I'm
> talking about an object that manages a subprocess. If a caller tries
> to call a method of the manager to interact with the subprocess when
> the subprocess
On Thu, Sep 01, 2022 at 03:11:29PM -0700, Bruce Leban wrote:
> * a stream-like object that has been closed and you attempt to read from or
> write data to it.
That would be a ValueError:
>>> f.write('a')
Traceback (most recent call last):
File "", line 1, in
ValueError: I/O operation on
On Fri, 2 Sept 2022 at 23:08, Stephen J. Turnbull
wrote:
> Bottom line: let's focus the argument on (1) where in the Python
> exception hierarchy the new builtin exception would go, and (2) per
> Paul Moore, if it could be used in the interpreter (I will add, or in
> a variety of stdlib modules),
Steven D'Aprano writes:
> A closed file is not *invalid*, it is just closed.
I think it's not very useful to focus on the individual words used
here. I believe that Steve J's idea here is related to the fact that
an object is a namespace and an environment. So the operation is not
"read from
