Passing information between modules

[Barry]

> On 21 Nov 2022, at 21:23, ram at zedat.fu-berlin.de wrote:
> 
> dn <PythonList at DancesWithMice.info> writes:
>> Now, at the config stage, take the instructions to define whichever the 
>> user prefers, and instantiate that class. Then the 'calling-routine' can 
>> use the instantiated object as an interface to whichever type of output.
> 
>  I had many different functions that are supposed to take
>  a "context" argument. If I would make them all methods of
>  a class with a "context" field, that would be a huge class
>  containing methods with many different purposes, which
>  reminds of the "anti pattern" "God class".

Do you haves lots of free standing functions? Are all these functions
not part of classes?

> 
>> with Environment() as env:
>>    # processing
>> There would be no need to explicitly prevent any 'processing' if the 
>> set-up doesn't work, because that context manager class will handle it all!
> 
>  Yes, but my problem was not so much with setting up the env,
>  but with passing it to many library functions.

Are you writing procedural code or object oriented? Why do you have so
many functions outside of a small number of classes?

> 
>> Is this how you implement?
> 
>  I'm not sure whether I understand the meaning of this question.

You appear not to be doing object oriented design.

> 
>  My library had a "console context" (before I started to use
>  the Python logging facility instead). That console context was
>  the default for output of progress and error messages.
> 
>  A client had the possibility to call functions with a custom
>  context, and then the function would use this custom context
>  for progress and error messages. The custom context could
>  direct those message to a text field in a GUI, for example. 
> 
>  Instead of passing this custom context to many library
>  functions, it might be simpler to "pass it to the library
>  once". This could be done via:
> 
> import library
> library.context = my_GUI_context

That is not oo design. I get the feeling that you need a better understanding
of how to structure a non-trivia library.

If you need the context object then you must pass it around.

> 
>  , but I wonder whether this "writing into another module"
>  is really possible in every Python implementation and whether
>  it will still be supported in the future. I do not see such
>  a pattern being used with the standard packages and suppose
>  that there might be a reason for this!
> 
>  The same question applies to the more advanced technique of
>  using "importlib.util.find_spec", "importlib.util.module_from_spec",
>  and ".__spec__.loader.exec_module" to even support having
>  different instances of a single module with different globals.
> 
>  I can now formulate my question this way:
> 
>  Many functions of a library have in their source code calls
>  like "PRINT( f'Done. Output was written to {filename}.' )".
>  The library uses "print" as a default for "PRINT", but
>  should explicitly support clients substituting a custom
>  implementation to be used for "PRINT". What's the best way
>  for the client to "pass" his custom implementation to the
>  library (which is a package or a module)?

Each place you have PRINT you need to have context.print calls.
You said above that you have, or had, such an object - pass it around and use it.

If passing it around is the problem then you need to look at why you code
has that problem.

Barry

> 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
>