WedWonder: Scripts and Modules
DL Neil
PythonList at DancesWithMice.info
Thu Sep 12 16:40:02 EDT 2019
On 12/09/19 10:59 AM, Cameron Simpson wrote:
> On 12Sep2019 08:24, DL Neil <PythonList at 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
More information about the Python-list
mailing list