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@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
--
https://mail.python.org/mailman/listinfo/python-list
