WedWonder: Scripts and Modules

[DL Neil]

On 12/09/19 8:43 AM, Chris Angelico wrote:
> On Thu, Sep 12, 2019 at 6:34 AM DL Neil via Python-list
> <python-list at python.org> wrote:
>>
>> In this day-and-age do you have a script in live/production-use, which
>> is also a module? What is the justification/use case?


> Yes, absolutely. It's the easiest way to share code between two
> scripts. Here's an example that I created recently:
> 
> https://github.com/Rosuav/shed/blob/master/BL1_find_items.py
> https://github.com/Rosuav/shed/blob/master/BL2_find_items.py
> 
> These programs do similar jobs on very different formats of file, so
> there's a small amount of common code and a large amount that isn't
> common. One of the common sections is the FunctionArg class, which
> ties in with argparse; it's implemented in BL1_find_items, and then
> imported into BL2_find_items.
> 
> Of course I could break this out into its own dedicated file... but
> why bother? It's not significant enough to warrant its own module, and
> I don't see any value in an importable file of "all the stuff that I
> might feel like importing"; it's just these two files that will need
> this.
> 
> Basically, the script/module distinction is a convenient way to
> simplify a common situation that doesn't need the overhead of anything
> else. If the code starts getting used in lots more places, it'll
> eventually get promoted to actual module.


Thanks for such a rapid response!

Interestingly, we appear to have opposite approaches to this situation - 
as soon as I think the word "common" it morphs immediately into "module".

I have also needed to scan a directory/tree recently, but took the 
course of refactoring a previous implementation's 'directory-walk' code 
into its own (generator) function, and thus the mainline of the newer 
application calls the utility function and chooses whether or not to 
deal with each 'found' file/dir in-turn. The previous script using the 
code was similarly refactored.
(and there are no doubt ?many more scripts 'lurking' in my code-base 
which could be similarly 'improved' - such frequent commonality leading 
to my preference).

My bias (I'm not criticising/complaining about/decrying the choices you 
have illustrated) probably comes out of "separation of concerns". An 
issue which has 'bitten' me, more than once...

For example both BL1 and BL2 feature:

def money(savefile): savefile.money[0] += 5000000 # Add more dollars

- a minor issue, agreed (and 'picking on it' purely to make a point).

The "s-o-c" is, that one day it will be possible to decide that the unit 
of addition should change, but only (remember to) amend the code in one 
of the two scripts!
(when it comes to trusting my memory, I'm an 'old git' with history, but 
not an old git repo with "history"!)

Which brings me back to the preference for 'encapsulation' (just to 
prove I can speak "OOP"), and why I would have written quite separate 
'main-lines' and extracted money() (and presumably a lot more) into a 
module which could then be called by both.


Aside1:
However, you've started me thinking about a related 
consideration/philosophy (Danger Will Robinson!) - but please let me 
cogitate on that for a day or so...

Aside2:
Meantime, thanks for the opportunity to review your code. I was thinking 
of considering "data classes" (new in v3.7, IIRC) in relation to an SQL 
interface on today's ToDo list - constructing the application's queries 
and the data transfers 'in' and 'out', without the 'weight' of 
SQLAlchemy. Perhaps?

-- 
Regards =dn