Python best practice instantiating classes in app

[DL Neil]

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