On 12/09/19 10:59 AM, Cameron Simpson wrote:
On 12Sep2019 08:24, DL Neil <pythonl...@danceswithmice.info> 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?
Many. Many many.
1: Many of my modules run their unit tests if invoked as the main
programme.
I used to do this, but now prefer to keep tests in separate modules -
and separate directories.
2: Several modules are their own utility programme. I've got a heap of
these - anything that provides useful access to something can often be
usefully used from the command line.
This is an very interesting idea - you're way ahead of me on this!
Would it be fair to describe these as more Python for systems
programming/system administration, than an application for (simple) users?
(what other kind is there???)
Consider: if you write a package, would it have a __main__.py?
Well, if the answer is ever "yes" then the same applies to ordinary
modules, simple enough to not be worth splitting onto a package.
May not properly appreciate this point...
So, yes, for me this is really really common.
Even for my current client project, which is largely a package, several
of the individual modules within the package have their own main
programmes for testing and for various utility tasks dealing solely with
that particular subsystem. There's an overarching shell script to set up
the environment and then do various things from the command line, and it
directly invokes particular modules for some operations that act only on
one subsystem.
Interesting!
Gives me pause for thought: perhaps I lean too heavily on putting
'stuff' in the test routines (and view the application from that
'direction' too often).
Multiple entry-point systems seem relatively unusual these days -
perhaps a natural flow-on effect of the rise of gui- and menu-based systems?
With one client, over the years, we've developed a number of (basically)
statistical analyses. Each analysis was born from a separate project.
Each lives in its own directory (tree). There are some common modules
held in a separate 'utility' library/package/directory. Whilst it has
been suggested, the idea of an "overarching" menu-type top-level
controller/distributor has never risen up the ranks of the "backlog"
(sensible criticism: the money would be better spent on other
priorities) - they (or at least the older ones) are quite happy to
'drop' to the command line and type the required command+args. I think
that's the closest I come to what you have described. (out of interest)
Would you characterise it as a common project structure?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
