Friday Filosofical Finking: Import protections

[Chris Angelico]

On Fri, Apr 19, 2019 at 3:27 AM Akkana Peck <akkana at shallowsky.com> wrote:
>
> Chris Angelico writes:
> > Actually, only the Python interpreter has to be able to do those
> > steps. That's why I put the comment *on the same line* as the import
> > statement (not immediately above it, for instance). It comes out like
> > this:
> >
> > (env) rosuav at sikorsky:~/shed$ python3 BL2_find_items.py
> > Traceback (most recent call last):
> >   File "BL2_find_items.py", line 19, in <module>
> >     import lzo # ImportError? pip install python-lzo
> > ModuleNotFoundError: No module named 'lzo'
> > (env) rosuav at sikorsky:~/shed$
>
> Oh, I see: because it prints the full line that caused the exception.
> Clever!

Yes - provided the .py file is available. If you delete the .py file
and just run the .pyc, this doesn't work. (Another reason not to do
that, honestly.)

> > > for regular users, when you know an error is both likely and unclear
> > > to read, it might make sense to catch the exception and print
> > > a clearer message.
> >
> > Define "clearer", though. Given that many MANY users won't read *any*
> > error message, the clarity becomes largely moot, and only a handful of
> > people will (a) read what you print out, (b) be able to resolve the
> > problem, and (c) not be able to figure it out from four lines of
> > output.
>
> When writing programs for general use (which this admittedly wasn't),
> it seems sad to accept unclear errors on the assumption that some
> users don't read error messages. Even most of the nontechnical
> users I know will read a one-line error message, though they
> certainly wouldn't try to read a 4-line stack trace. I usually try
> to catch errors that I expect will be common, and print something
> clearer than the default traceback.

TBH, I don't think the default message is all that unclear. It does
lack any sort of "how to solve this" information, but that can be
provided by the comment. Something that frequently annoys me in terms
of debugging is something that "knows better" - it absorbs a nice,
useful, helpful message, and spits out one bland, generic message,
based on what the developer THINKS is the cause. Remember: You will
*never* think of everything that can go wrong.

ChrisA