Dave,
On 30/04/19 7:36 AM, Dave wrote:
On 4/29/19 3:26 PM, Terry Reedy wrote:
On 4/29/2019 1:38 PM, Dave wrote:
As apps get more complex we add modules, or Python files, to organize
things. One problem I have is a couple of data classes (list of
dictionary objects) in a few modules that are used in a number of the
other modules. For example a list of meter reading dictionaries in
one module is used by the user interface module to get the data from
the user, a report module to display the data, and a file module to
save and retrieve the data to/from file. All the modules need to use
the same instance of the list classes.
There are a number of ways to do this. One is a module that creates
the objects, then import that module into all of the others. Works
well,
You can have one *or more* such modules. Perhaps you already do.
but may not be the best way to do the job.
In what way do you consider it unsatisfactory.
It is not that I consider it unsatisfactory as much as I'm looking for
the best way. I am constantly amazed at the thought that has been given
to this language (with the exception of access modifiers - perhaps, and
lack of a case statement), and often find that there is a better way of
doing everything.
A slight variation is to do this in the main module, but the main
module has to be imported into the others.
Avoid import loops unless really necessary. They often work, but when
they don't ... its a pain.
Since I use the main module as a calling module to load data, start
the user interface, and to close things down, it may not be the best
place to also create the classes.
Another way to do this is have a line in each module to check the
name. If it is the module name, then create the class and then import
these modules in all the others. A tad messy and maybe a little
confusing.
Right.
My preference is for as little 'clutter' on the 'mainline' as possible.
Reading the code (and comments) should illustrate the approach being
taken and provide an overview. NB Others may prefer otherwise, eg many
PSL packages!
That means most/all classes are import-ed from a package/module.
So, the 'mainline' features:
from meters import meter_dict
from meters import Meter # class named Meter
...
meter = Meter( type=meter_dict[ key ] )
This allows any/all related applications to do the same.
Again, IMHO, import-ed modules are best kept-organised in a separate
directory.
As long as all of these 'related applications' which will import the
module can be kept in one dir, then the modules can be located in a
sub-dir, ie a sub-dir common to all apps.
However, if there is a need to separate applications, eg security/access
control, then life becomes a little more complex...
The other issue is that if two new programs are designed together and
import the same module, everything will work well - at the start.
However, if the module must be changed to suit (only) one of the
applications, then such changes need to be made with (all) the other
applications in-mind!
Failing that, you'll wind-up with multiple versions of modules. Here be
dragons!
There was a discussion 'here' a few weeks ago, which may yield some
interesting thoughts: "Handy utilities = Friday Filosofical Finking".
Check in the archive (access link, as footer)...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
