On 2019-04-17 21:20, DL Neil wrote:
(I know it's not Friday [exp], and after personal apologies[apo])
Do you bother with exception handling for import statements?
Most of the code I read, both in books and during code review, eschews
any form of ImportError check. Even data science people who 'clean'
every data field towards inclusion/exclusion in the analysis, take for
granted that numpy, scipy, pandas, et al, will be available to their code.
Does such a check seem un-pythonic? [sto] (maybe 'forgiveness cf
permission'?)
Can we assume that if such a catastrophic error occurs, it is quite
acceptable for the code to fall-over in a tumbling-fumble?
Does it make a difference if operating in/out of a dev-ops environment?
Might such only occur once, because once the environment has been
correctly-built, it will/can *never* happen again?
Can we assume Built-in and PSL modules *must* be present, so we only
need to talk about covering in-house code and pip-ed (or similar) modules?
Is it more/less important in __main__ than in an imported module?
Do you handle each import separately, or all in a single try..except block?
Do you try to anticipate and cover every import in the system at the top
of __main__, eg imports inside imported modules?
What about OpSys-specific imports (etc)?
Do modules import-ed only in specific situations, deserve more, or less,
attention?
[snip]
Catch only what you (well, the script) can fix.
If it needs numpy, but can't import numpy, then when can it do? Might as
well just let it fail.
I suppose an alternative might be to try to download and install numpy
and then retry, but what if it can't be downloaded, or the installation
fails?
No, you have to give up at some point. It's better just to report the
problem and leave it to the user to fix it.
--
https://mail.python.org/mailman/listinfo/python-list
