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
--
https://mail.python.org/mailman/listinfo/python-list
