Passing information between modules

Dan Kolis dankolis at gmail.com
Sun Nov 20 16:16:18 EST 2022


Using sys.stdout / is simply nonsense. The more I think about it, the more I realise how bad it is.

Going on about it endlessly seems pointless.

If the even mini threading thing is turned on, now what ? some other module eats the message intended for a different module ? A state machine with its own matching code in sends and receives to reuse the unwanted singular value ?

The precise rules for establishing a variable without the global keyword is not obvious, or catcat of anything  by leaving a empty set dangling initially.

*especially* if the program is fundamentally open ended, that is, there could be considerable new functions sharing ideas all over, planning ahead for as good 45 seconds is a lot better then endless hacking any old way.

1) Make a variable in a module known to be a shared item. Named for that specifically.
def Mt() {}
IoDot = {} # Once before program does anything... in global. ref import global as gi later.

2) Create highly generalised speculative named ideas init each variable once with a {}
ioDot.weights = Mt{} ; ( I make it a local method so the method can stand alone for unit testing )

3) Uniformly ref it with a import statement. in all 'other' modules

4) When a shared idea is apparent concat a new named portion to the name for this purpose. Then use those fairly without fussing as required. If one scares you, set it to {} after some scary moment if you are feeling fussy.

5) All 'ideas' will be at a 3rd or more subsid level in naming. ex:

gi.IoDot.weights.trucks = whatever
gi.IoDot.weights.cars = whatever

gi.toastDot.warnings.tooHeavy
gi.toastDot.warnings.isOk

These can all be any kind of object. So easy

I have a very sizable highly generalized program using this and have not found any defect in doing so.

Regs
Dan

 



More information about the Python-list mailing list