On Sun, Oct 3, 2021 at 8:00 AM Jonathan Crall <erote...@gmail.com> wrote:
> 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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JK6LQRQIWF6CD4MIXW5RC6FNX4ZEN423/
Code of Conduct: http://python.org/psf/codeofconduct/
