dahult
Posts: 1
Joined: Mon Sep 18, 2017 2:25 pm

Preloaded *phat* modules in Python

Mon Sep 18, 2017 2:57 pm

Sometime a few months back, the builds have started to include the 'phat' python modules. Frankly, I don't think these modules are well written and do not think they should be in the standard build. When they originally showed up they caused python3 to abort when doing a simple help('modules').

It appears in the owners of these modules fixed that abort problem, but are now causing new trouble. On a Pi with an explorer-pro, when I do a help('modules') I get 2 messages "Automation pHAT detected..." and "Explorer HAT Pro detected...". I don't have an 'Automation pHat on this Pi. Also, when I exit python3 I get the messages:
Explorer HAT exiting cleanly, please wait...
Stopping flashy things...
Stopping user tasks...
Cleaning up...
Goodbye!

I don't know what 'flashy things' or 'user task' do but I am sure they were started by just listing the available modules (help('modules') and the automatic detection on the explorer hat.

These modules are doing way more than they should. I am sure the intention was to preload to make it easier for novice Pi users but they are causing problems.

gadgetoid
Posts: 152
Joined: Wed Mar 07, 2012 9:58 pm

Re: Preloaded *phat* modules in Python

Mon Sep 18, 2017 6:09 pm

Ahoy!

Author here. Guilty as charged. I was only recently made aware that the side-effects at module load time actually have knock-on effects that I didn't know about when I originally went with this pattern.

Yes the intent was to make it easier for beginners, and since the libraries interact with hardware having a singleton module made a lot of sense. This pattern was first deployed in the Pibrella library over 3 years ago and I stuck to it without ever re-evaluating whether I should as I grew more experience with Python.

Anyway, excuses don't fix anyway. I've actually been evaluating approaches to fixing this exact problem across all of our libraries without creating spaghetti code or breaking backwards compatibility too much.

Since it's across a number of libraries relating to a number of physical products and, to boot, we're undergoing something of an office re-arrange at the moment it's going to take some time to fix, test and deploy each library. But it's in progress!

In the interim I'm not sure what can or should be done- but I suspect it would be in our best interests to get these packages fixed before the next Raspbian release lest this problem warrant their removal; which would be unfortunate :(

Thanks for bringing this up, anyway, since we don't intend our packages to be bad Python neighbours.

Return to “Python”