One of the motivations of this proposal is to incentivize writing code in a local scope, rather than a global one.
I'm not sure that's something to be incentivised necessarily ;-)
Yes, incentivising good code structure is a good thing, but using global scope for scripts isn't necessarily a bad thing -- an it actually makes debugging scripts a touch eraser -- e.g. I like to use iPython's `run`- and then i have those global names right there, ready to use,
> One of the motivations for me posting this was a several students I was working with were putting all of their logic in the `if __name__ == '__main__'` block, defining global variables in them, and then relying on those global variable existing in other places in the code.
I think the problem there is overuse of the __name__ block -- why have it at all? I suspect these students saw that pattern and thought is was necessary, much like a main() function is necessary in some languages.
After all, they had already done the "hard part"of writing that awkward if black, calling a function in it would have been no harder, if they were using functions at all. With my students, I start them aff writing scripts, then work on moving logic into functions, and later on introduce the if __name__ block (normally for simple tests first)
@
Christopher Barker
> The if __name__ block is only required for a Python file to be both a module and a script.
> That’s actually a pretty uncommon thing—
I suppose I do an uncommon thing fairly often. I work with neural networks and I generally construct a package with a pkg/fit.py pkg/predit.py and pkg/evaluate.py which all operate as both a module and a script. I'll run `python -m pkg.fit [args]` to train a network but I'll also `from pkg import fit`, especially when testing. I think if you are testing an executable module you almost always want to have part of it be importable so it can be unit tested.
absolutely -- but why does you code really fit into that neat structure where all the functions are only needed by a particular script? For the most part, once I've made a package, I'd have a collection of functions, etc, and then each script would import and use a different subset of those code -- but it's not a 1:many relationship, it's many:many So the "real code" wouln'dt be in the same files as the scripts.
And may have one script with opttions:
./this_model fit
./this_model evaluate
...
Anyway, I do think your example of scripts needing multiple testable functions that are used only by that one script is actually pretty rare.
the simplicity of the case where it makes intuitive sense that the package module should be accessible as a module and a library.
did you mean "script" and a library ?
But anyway, that's what if __name__ == "__main__" is for -- no one's saying you shouldn't use it ...
Retrospectively, I would agree that this is probably uncommon, but if nothing else comes out of this discussion, I would want to encourage Python users to write Python files as both modules and executables more often. Having lots of entry points can be handy, and makes a lot of sense in many cases (e.g. whenever you have a main module with more than one function, it almost always makes sense to be able to import it to unit test the components).
Though if it's that coupled, maybe the unit tests should be in the same file as well :-) if you define a few "test_*" functions in aa file, you can pass the whole thing tto pytest to run them ..;.
Anyway --- I personally think if __name__ == "__main__" is a bit cryptic, and kins leaks an implementation detail -- after all, we don't usually access dunders directly -- e.g. len(something) rather than something.__len__() -- so I'm pefer something like:
if running_as_a_script:
do the stuff.
But is it worth a change now? the if __name__ == "__main__" idiom has been around a long time -- it will be supported forever, and examples and explanations of it will be around a avery, very long time -- making a new way now will only add a lot of confusion for years, with only a little benefit.
-CHB
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython