On 12/09/19 8:22 PM, Barry Scott wrote:
On 11 Sep 2019, at 21:24, 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?
(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
--
https://mail.python.org/mailman/listinfo/python-list
