WedWonder: Scripts and Modules

[DL Neil]

On 12/09/19 8:22 PM, Barry Scott wrote:
> 
> 
>> On 11 Sep 2019, at 21:24, 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?
>>
>> (discounting distutils and similar installation tools, or unit testing methodology)
>>
>>
>> There are over 500 questions on StackOverflow which refer to Python's
>>
>> 	if __name__ == __main__:
>>
>> construct. Even more if you include the idea of a main() multiple entry-point.
>>
>> This construct enables code to distinguish between being "run" as a "script", and being imported as a "module". (which is not in question)
>>
> 
> In my mind this is a question about what side-effects of importing a module are
> desireable and which are not.

Precise description!


> A trivia script does not need the __name__ == '__main__' as its all about its side effects.
> 
> As scripts become more complex having it run on import might make debugging harder
> and prevents reuse.

Is this an informal distinction: that modules are written for re-use but 
main-lines to be unique/single-purpose?


> For example I will import a script at the REPL and examine it and call function in it to
> help me understand and fix problems.  Having a __name__ == '__main__' is important
> to allow this.

Why?

If we import sys (from the PSL, purely as an example), we don't 
expect/need any execution phase, can immediately follow (in the REPL) 
with help(sys) and similar, and can debug/explore from there:

>>> import sys
>>> help(sys)

>>> sys.path
['', '/usr/lib64/python37.zip', '/usr/lib64/python3.7', 
'/usr/lib64/python3.7/lib-dynload', 
'/usr/lib64/python3.7/site-packages', '/usr/lib/python3.7/site-packages']


> I often have modules that are part of a larger program that have their own main() functions
> to unittest or give access to parsers etc.

and the main() is the sole content of the if __name__ etc structure?


> In large projects with many modules import with side-effect can make for a maintenance
> burden.


You seem to have unmasked an assumption under which I operate. (well 
done - you know what 'they' say about assumptions!)

As you say, (non-designed) side-effects are undesirable.

My 'rule' is that modules only contain definitions, eg classes and 
functions. Thus, *nothing* executes upon import.

During a code review, some eagle-eye, noticed (and questioned) I had 
re-factored some 'constants' which control a "switch" structure from out 
of the module-space, and into the class where they 'belonged', without 
having any other 'good reason'.


I have no recollection of the history or rationale for this 
policy/practice, nor can I remember whether it 'belongs to Python' or 
some other language from which I've imported it (hah, punny joke!) 
Perhaps it comes from my preference to from...import... rather than 
import...as... which largely eschews the module namespace?
(or perhaps I'm just a closet control-freak?)

That said, I'm sure there must be modules of my code which break this 
'rule', somewhere (certainly in the 'quick and dirty' department).

-- 
Regards =dn