On 11/20/2022 4:07 PM, Roel Schroeven wrote:
> Thomas Passin schreef op 20/11/2022 om 20:33:
>> https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35413
>> https://devblogs.microsoft.com/oldnewthing/20101125-00/?p=12203
>>
> Now that I think about it, The Old New Thing is also where I got the
> global vs local thing: "Don’t use global state to manage a local
> problem", https://devblogs.microsoft.com/oldnewthing/20081211-00/?p=19873
>

Bingo!

On 21/11/2022 12.07, Dan Kolis wrote:
> If you understand its meaning, it achieves my purpose. If you don't I you're perhaps not a programmer...

Ouch!

Does the first sentence imply who is the more important person in the
interaction? Does the second further the idea that anyone/everyone who
is not at your 'level' has no worth?

--
Regards,
=dn

On 11/21/2022 12:01 AM, dn wrote:
> On 21/11/2022 12.07, Dan Kolis wrote:
>> If you understand its meaning, it achieves my purpose. If you don't I
>> you're perhaps not a programmer...
>
> Ouch!
>
> Does the first sentence imply who is the more important person in the
> interaction? Does the second further the idea that anyone/everyone who
> is not at your 'level' has no worth?

Folks, this is getting into ad hominem territory. I suggest it's time
to end the thread, since it's no longer productive.

On 21/11/2022 01.29, Stefan Ram wrote:
> dn <PythonList@DancesWithMice.info> writes:
>> 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").
>
> Yeah, I had some functions of my library take such an "env",
> which in my library is called "context":
>
> def python_version_check( major=3, minor=9, context=x_default_context ):
> passed = _sys.version_info >=( major, minor )
> if not passed:
> requirements_info = "This program requires Python " + \
> str( major ) + "." + str( minor )+ "+.\n"
> version_info = "Currently running under Python {}.{}.\n". \
> format( *_sys.version_info[ :2 ] )
> context.warning( requirements_info + version_info )
> return passed
>
> . But so far I am using "context" only for logging, so I am
> now thinking about replacing with Pythons logging facility.
>
> One possible application of "context", however, would also be
> normal output, which has to be shown to the user, not only
> logging as in:
>
> def show_sum( x, y, context=x_default_context ):
> context.print( f'The sum is {x+y}.' )
>
> . For example, there could by a "GUI context" by which
> "context.print" would append the output to some GUI text
> field. Using the logging facility to output text that must
> be show to the user, would abuse logging somewhat.
>
> def show_sum( x, y, context=x_default_context ):
> logger.log\
> ( my_custom_level_for_output_to_user, f'The sum is {x+y}.' )
>
> Or one could "print patch" a module, via (using the class from
> a recent post of mine):
>
> M = prepare_module( 'M' )
> M.print = my_gui_print_function
> M = M.load()
> M.f()
>
> and "show_sum" would be simply:
>
> def show_sum( x, y, context=x_default_context ):
> print( f'The sum is {x+y}.').
>
> My original question probably was intended to be something
> like: "Today, we can add attributes to a module from the
> outside. How large is the risk that this will be forbidden
> one day, so that all code using this will stop working?".

Am put-off by the 'smell' of subverting/adapting names like print() =
surprise/confusion factor - but I think I understand where you're going.

What about an ABC which is inherited by two classes. One class handles
all the detail of output to GUI. The other, similarly, output to the
terminal, log, (whatever). The ABC should require an output() method,
with suitable signature. The two classes will vary on the fine detail of
the HOW, leaving the calling-routine to produce the WHAT.

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.

If the choices on-offer include not just either/or, but also 'both of
the above'. The instantiation would need to be a class which called both
class's output() method serially.

Your use of the word "context" provoked some thought. (you don't know
just how dangerous that could become!)

In many ways, and as described, an Environment/context class could be
very easily coded with formal __enter__() and __exit__() methods. The
mainline might then become:

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!

NB haven't had time to try this as a refactoring exercise.

Is this how you implement?

--
Regards,
=dn

On Mon, 21 Nov 2022 at 16:26, dn <PythonList@danceswithmice.info> wrote:
> Am put-off by the 'smell' of subverting/adapting names like print() =
> surprise/confusion factor - but I think I understand where you're going.

To be fair, redefining the "print" function IS one of the reasons that
it's no longer a statement. Though I would generally recommend
maintaining its signature and purpose.

ChrisA

dn <PythonList@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".

>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.

>Is this how you implement?

I'm not sure whether I understand the meaning of this question.

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

, 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)?

On 11/21/2022 12:24 AM, dn wrote:
>> My original question probably was intended to be something
>>    like: "Today, we can add attributes to a module from the
>>    outside. How large is the risk that this will be forbidden
>>    one day, so that all code using this will stop working?".

This can happen today if, for example, a class is changed to use slots
for everything. Between slots and type checking, it can become
impossible to add an arbitrary attribute. *You* may be able to avoid
this, but if you use someone else's modules or classes it could happen
at any time.

I might regret the loss of being able to assign an arbitrary attribute
wherever I like, but for complex libraries, it is probably a good idea
in the long run.

> On 21 Nov 2022, at 21:23, ram@zedat.fu-berlin.de wrote:
>
> dn <PythonList@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
>