On Wed, Apr 13, 2016 at 1:47 PM, Random832 <random...@fastmail.com> wrote:
> On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote:
> > so are we worried that __fspath__ will exist and be callable, but might
> > raise an AttributeError somewhere inside itself? if so isn't it broken
> > anyway, so should it be ignored?
>
> Well, if you're going to say "ignore the protocol because it's broken",
> where do you stop? What if it raises some other exception? What if it
> raises SystemExit?
this is pretty much always the case with EAFTP coding:
try:
something()
except SomeError:
do_something_else()
unless SomeError is a custom defined error that you know is never going to
get raised anywhere else, then something() could raise SomeError for the
reason you expect, or some code deep in the call stack could raise
SomeError also, and you wouldn't know that.
I had a student run into this and it took him a good while to debug it. But
that was because the code in something() was pretty darn buggy. If he had
tested something() by itself, there would have been no issue finding the
problem.
In this case, I don't know that we need to be tolerant of buggy
__fspathname__() implementations -- they should be tested outside these
checks, and not be buggy. So a buggy implementation may raise and may be
ignored, depending on what Exception the bug triggers -- big deal. The only
time it would matter is when the implementer is debugging the
implementation.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
