Passing information between modules

[dn]

On 18/11/2022 23.53, Stefan Ram wrote:
>    Can I use "sys.argv" to pass information between modules
>    as follows?
> 
>    in module A:
> 
> import sys
> sys.argv.append( "Hi there!" )
> 
>    in module B:
> 
> import sys
> message = sys.argv[ -1 ]
> 
>    . "sys.argv" is said to be a list by the standard
>    documentation, so it should be guaranteed to be
>    appendable as lists are appendable.
> 
>    Moreover, in my own program, after its startup, third parties
>    do not inspect "sys.argv". So by appending something to it
>    (or modifying it) I do not tamper with information that might
>    be misinterpreted by any third party outside of my own code.
> 
>    Another hack might be:
> 
>    in module A
> 
> import builtins
> builtins.message = "Hi there!"
> 
>    in module B
> 
> import builtins
> message = builtins.message
> 
>    But I'm not sure whether modules (such as "builtins" here)
>    are guaranteed to be modifyable and visible by the language
>    reference in this way though


The re-use of built-in features is risky, if only because of the remote 
possibility that a future version of Python will add something that 
clashes. That's why Python makes such good (and careful) use of namespaces!

In some respects we have the (OP) problem because Python does not have 
"interfaces" as a formal component of the language. So, we often 
get-away with taking an easier course - but in doing-so, may forget that 
they serve specific purposes.


There is a general idea that globals are harmful, a code-smell, etc; and 
therefore something to be avoided. However, the global namespace is a 
(built-in!) feature of Python, so why not use it?

The problem comes when we try to re-use module A or B in some other 
application. It may not be relatively-obvious that some global, eg 
config, must be previously-defined and made-available. If you're 
prepared to accept that risk - and presumably combat the criticism by 
carefully (and prominently) documenting it, just as with any other 
docstring, where's the problem? (caveat emptor!)


Considering the use-case, it is unlikely to be as trivial as the 
example-given (OP). A classic example would be set of credentials to 
access an RDBMS and specific table(s).

A 'standard' solution is to collect all such configuration-data at the 
start of the application, into an object (or other data-structure) - I 
usually call it "env" (an instantiation of "Environment").

Thereafter, when needing such data within a module, calling the 
particular function/class/method by name (moduleNM.function(...) ), and 
passing only that section of the env[ironment] required. Such achieved 
by passing some sub-structure of env, or by passing a retrieval/get method.
(a module handling GUI, for example, has no business looking at 
RDBMS-creds - which it would be able to do if the whole env was passed!)


but...

the module's code will expect its data in a particular form (an 
interface!), which must be documented and understood by both the 
provider and consumer (people and software)

- which sounds like the same 'solution' to the 'globals problem'...

-- 
Regards,
=dn