Closed WayneKeenan closed 6 years ago
I just replaced the exit's with warnings, but raising an Exception might be a better design.
For the i2c fallback nobody would want the library to depend on picraftzero.thirdparty.mocks.raspiberrypi.rpidevmocks
or the rpidevmocks
PiCraftZero uses.
Perhaps this library could do it's default behaviour unless an optional i2c_provider
option was passed to the constructors/init or a module global?
Raising an Exception is something I've considered, instead of printing out an explicit message, since it's technically the right way to handle these cases.
Unfortunately, beginners simply do not read Exception messages, or are incapable of parsing out the bit that matters - the exception text - from the backtrace that Python vomits up. Explicitly printing out a concise error is a compromise and an attempt to produce more friendly error output for beginners.
It's a shame there's no way to pass a module some state before importing it, to switch into "expert mode" for more complex projects relying on our libraries.
All of our libraries use an instantiate-on-import singleton pattern which is fantastic for beginners but horrible for building them into more complex projects. So far I haven't found a satisfactory way to serve both needs.
How about reading an environment var at import time at the top of the the explorer module which sets an internal flag for:
logger
or print
should be usedThere could be 2 new internal functions, e.g. log
and error
in place of print
and exit
respectively that did the flag check in single place, otherwise it's most messy.
This could be a single 'master switch' env var and without the env var set by default the library would do the existing behaviour.
We could call this env var 'WAYNES_WORLD', but that's not precious to me. :)
If I put a PR together and you provided an ENV var name, would you kindly take a look?
EDIT: I'm also looking at the same for the pan/tilt module too. (To start with :) )
the i2c part is another matter, thats a bit more involved and potentially need to look at i2c factories with at least 2 different implementations (one being as it is now), also set by env var. Akin to how gpiozero uses pin factories.
Perhaps split the library internally into a core api for 'advanced' usage and use the core to (re)create the existing 'beginner' api.
Note: I've created PRs against most of our libraries (including this one: https://github.com/pimoroni/explorer-hat/pull/36) that- along with not doing anything silly at import time- change them to simply raising an exception in an import error condition. I made a lot of concessions to hand-hold beginners with our libraries, and may have pushed a bit too far- breaking some Python fundamentals in the process. I'm keen to rectify that.
Hopefully this will make your life easier!
Hiya, this is more of a query and perhaps start of a discussion.
I've embedded a modified version of the explorer library in PiCraftZero.
I've included a diff below to highlight the details, although it's not intended as a PR or patch as it is.
In summary the tweaks are:
exit()
on errors - a requirement to co-exist with other code and to do graceful fallbackIt would be nice to get all these into explorer hat library in some way, perhaps as injectable/configurable overrides in some cases, instead of having to import my bootlegged version in user scripts for example.
The diff: