> On 21 Nov 2022, at 21:23, r...@zedat.fu-berlin.de wrote:
>
> dn <pythonl...@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
>
--
https://mail.python.org/mailman/listinfo/python-list
