Re: Passing information between modules
There is no guarantee that argv is consulted earlier in the program than other modules will use it for communication. Consider a case where a program does look at argv but later wants to call another program using some or all of the components of argv and now there are added components there. That could lead to all kinds of problems. Some languages have global objects available that you can add to, sort of like a dictionary object and as long as you add keys guaranteed to be unique, can be used carefully to coordinate between parts of your program. Of course, you may also need to use techniques that ensure atomic concurrency. Reusing argv is a hack that should not be needed. On Sat, Nov 19, 2022, 4:37 PM Thomas Passin wrote: > On 11/19/2022 4:28 PM, Thomas Passin wrote: > > On 11/19/2022 3:46 PM, Michael F. Stemper wrote: > >> On 18/11/2022 04.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 ] > >> > >> I just tried and it appears that one can append to sys.argv. However, > >> it seems like an incredibly bad idea. > > > > For that matter, you can just directly add attributes to the sys module, > > no need to use sys.argv: > > > > >>> import sys > > >>> sys._extra = 'spam' # Not an exception > > >>> print(sys._extra) > > spam > > > > Probably not the best idea, though. Better to use some module that you > > control directly. > > This could be one of those things of which Raymond Chen (The Old New > Thing) asks "what if everyone did this?". Imagine if every > (non-standard-library) module misused sys or sys.argv like this. The > result could be chaotic. > > Best to put all your own stuff into modules that you yourself control. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
It's certainly not an "incredibly bad idea", it is a mildly bad idea however. Why be stuck with maybe's and just text strings ? Functions as "first class operators" and object oriented languages are a natural pair with a bit of heavy thinking. The problem is... there is nobody giving you a 3 line solution without thinking. Its a 7 line solution requiring understanding. One you do it right, then its a 2 line solution ! Once you construct the bridges; then, in any module you can consider global sharables like so: First vague use of functionality gi.setAsideArea.NewIdea = 'ok' Next usages anywhere ! gi.setAsideArea.NewIdea = "StateMachine Argon" There is no hangover of vague ideas bothering future executions of the code either. This is not some scary file buried in a directory system which needs calling and might be stale, using bad ideas, etc. How much easier can a solution be ? Regards, Daniel B. Kolis -- https://mail.python.org/mailman/listinfo/python-list
Re: An email from a user
Hi, I recently installed Python 3.11.0 on my laptop. However, there was no folder named 'Python' in my Program folder after the software was installed. I'm writing this letter since I'm a python learner and the loss of the Python folder in the Program folder seems to cause the Pycharm on my computer unable to import the pandas module. I'm really distressed since I have to get this problem solved to earn grades on my course. I would appreciate it if you can help me evaluate the issue. Best regards, Hoe Tee On Sun, 20 Nov 2022 at 17:14, Hoe Tee wrote: > Hi, I recently installed Python 3.11.0 on my laptop. However, there was no > folder named 'Python' in my Program folder after the software was > installed. I'm writing this letter since I'm a python learner and the loss > of the Python folder in the Program folder seems to cause the Pycharm on my > computer unable to import the pandas module. > > I'm really distressed since I have to get this problem solved to earn > grades on my course. > > I would appreciate it if you can help me evaluate the issue. > > Best regards, > Hoe Tee > -- https://mail.python.org/mailman/listinfo/python-list
Re: An email from a user
On 11/20/2022 7:32 AM, Hoe Tee wrote: Hi, I recently installed Python 3.11.0 on my laptop. However, there was no folder named 'Python' in my Program folder after the software was installed. I'm writing this letter since I'm a python learner and the loss of the Python folder in the Program folder seems to cause the Pycharm on my computer unable to import the pandas module. I'm really distressed since I have to get this problem solved to earn grades on my course. I would appreciate it if you can help me evaluate the issue. These days, Python usually installs on Windows into %USERPROFILE%\AppData\Local\Programs. Here, %USERPROFILE% means your user directory, which is usually at c:\Users\. You can type %USERPROFILE% directly into the box at the top of Windows Explorer. If Pycharm cannot find Pandas, it is probably because Pandas has not yet been installed with the new Python 3.11. You would need to install it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
Stefan Ram schreef op 20/11/2022 om 11:39: The idea is about parameterizing the behavior of a module. For example, the module "M" may contain functions that contain "input.read()" to get input and "output.write()" to write output. Then one would write code like (the following is not correct Python code, just pseudo code assuming a possible extended Python where one can assigned to a module before it's loaded): import sys M.input = sys.stdin M.output = sys.stdout import M . So now M would use sys.stdin for input and sys.stdout for output. I feel this is a bad idea. This uses global state for customizing local behavior. Yes, maybe you want to customize behavior in one of your modules, or even only in some functions, or maybe in several or even all of your modules. But by changing module "M", you're changing it for *every* user of it, even for standard library modules or third party packages. You can't customize it in different ways in different parts of your code. And it's a kind of spooky action at a distance: the behavior of a module gets changed by another, possibly completely unrelated, module. This has the potential to grossly violate the principle of least surprise. If someone else would ask this, I'd tell him to use a class: import MM import sys M = MM.moduleclass( input=sys.stdin, output=sys.stdout ) That is a *much* better solution, and I would even say it's the only acceptable solution. , but this is another layer of indirection, so it's a bit more complicated than the direct approach of parameterizing a module. I'm not even sure it's more complicated. It's more explicit, which I like. You could have a hybrid approach, like what the random module does. The functions in the random module are actually methods of a global hidden instance of class random.Random; if you want random generators with separate states you can create your own instance(s) of random.Random, or of random.SystemRandom. -- "You can fool some of the people all the time, and all of the people some of the time, but you cannot fool all of the people all of the time." -- Abraham Lincoln "You can fool too many of the people too much of the time." -- James Thurber -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 21/11/2022 01.03, Stefan Ram wrote: dn writes: In some respects we have the (OP) problem because Python does not have "interfaces" as a formal component of the language. What one can do today is, class my_interface( metaclass=abc.ABCMeta ): """This interface ...""" @abc.abstractmethod def method( __self__, *s, **x ): """This abstract method ...""" # ... my_interface.register( my_class ) # ... Ugh! -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 11/20/2022 1:50 PM, Roel Schroeven wrote: Stefan Ram schreef op 20/11/2022 om 11:39: The idea is about parameterizing the behavior of a module. For example, the module "M" may contain functions that contain "input.read()" to get input and "output.write()" to write output. Then one would write code like (the following is not correct Python code, just pseudo code assuming a possible extended Python where one can assigned to a module before it's loaded): import sys M.input = sys.stdin M.output = sys.stdout import M . So now M would use sys.stdin for input and sys.stdout for output. I feel this is a bad idea. This uses global state for customizing local behavior. Yes, maybe you want to customize behavior in one of your modules, or even only in some functions, or maybe in several or even all of your modules. But by changing module "M", you're changing it for *every* user of it, even for standard library modules or third party packages. You can't customize it in different ways in different parts of your code. And it's a kind of spooky action at a distance: the behavior of a module gets changed by another, possibly completely unrelated, module. This has the potential to grossly violate the principle of least surprise. If someone else would ask this, I'd tell him to use a class: import MM import sys M = MM.moduleclass( input=sys.stdin, output=sys.stdout ) That is a *much* better solution, and I would even say it's the only acceptable solution. , but this is another layer of indirection, so it's a bit more complicated than the direct approach of parameterizing a module. I'm not even sure it's more complicated. It's more explicit, which I like. You could have a hybrid approach, like what the random module does. The functions in the random module are actually methods of a global hidden instance of class random.Random; if you want random generators with separate states you can create your own instance(s) of random.Random, or of random.SystemRandom. As I wrote, it's another case of "what if everyone did this". e.g.: https://devblogs.microsoft.com/oldnewthing/20050607-00/?p=35413 https://devblogs.microsoft.com/oldnewthing/20101125-00/?p=12203 -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
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 -- "In the old days, writers used to sit in front of a typewriter and stare out of the window. Nowadays, because of the marvels of convergent technology, the thing you type on and the window you stare out of are now the same thing.” -- Douglas Adams -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
Using sys.stdout / is simply nonsense. The more I think about it, the more I
realise how bad it is.
Going on about it endlessly seems pointless.
If the even mini threading thing is turned on, now what ? some other module
eats the message intended for a different module ? A state machine with its own
matching code in sends and receives to reuse the unwanted singular value ?
The precise rules for establishing a variable without the global keyword is not
obvious, or catcat of anything by leaving a empty set dangling initially.
*especially* if the program is fundamentally open ended, that is, there could
be considerable new functions sharing ideas all over, planning ahead for as
good 45 seconds is a lot better then endless hacking any old way.
1) Make a variable in a module known to be a shared item. Named for that
specifically.
def Mt() {}
IoDot = {} # Once before program does anything... in global. ref import global
as gi later.
2) Create highly generalised speculative named ideas init each variable once
with a {}
ioDot.weights = Mt{} ; ( I make it a local method so the method can stand alone
for unit testing )
3) Uniformly ref it with a import statement. in all 'other' modules
4) When a shared idea is apparent concat a new named portion to the name for
this purpose. Then use those fairly without fussing as required. If one scares
you, set it to {} after some scary moment if you are feeling fussy.
5) All 'ideas' will be at a 3rd or more subsid level in naming. ex:
gi.IoDot.weights.trucks = whatever
gi.IoDot.weights.cars = whatever
gi.toastDot.warnings.tooHeavy
gi.toastDot.warnings.isOk
These can all be any kind of object. So easy
I have a very sizable highly generalized program using this and have not found
any defect in doing so.
Regs
Dan
--
https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On Mon, 21 Nov 2022 at 09:37, Dan Kolis wrote: > > Using sys.stdout / is simply nonsense. The more I think about it, the more I > realise how bad it is. > > Going on about it endlessly seems pointless. > > If the even mini threading thing is turned on, now what ? some other module > eats the message intended for a different module ? A state machine with its > own matching code in sends and receives to reuse the unwanted singular value ? > > The precise rules for establishing a variable without the global keyword is > not obvious, or catcat of anything by leaving a empty set dangling initially. > > *especially* if the program is fundamentally open ended, that is, there could > be considerable new functions sharing ideas all over, planning ahead for as > good 45 seconds is a lot better then endless hacking any old way. You should print this out and get it on a t-shirt. It's a perfect example of AI-generated text. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
Its advice, I don't think the style issue is particularly important. If you understand its meaning, it achieves my purpose. If you don't I you're perhaps not a programmer... I like the abruptness of technical writing as a style, actually. If that is how machine learning ( aka 'A.I.' ) tends to compose messages, this seems mostly compatible with the sorts of written material I both make and consume. https://interestingliterature.com/2017/03/10-of-the-best-poems-about-forests-and-trees/ The whisper of the aspens is not drowned, And over lightless pane and footless road, Empty as sky, with every other sound Not ceasing, calls their ghosts from their abode, there's one for you... a click will get you nine more. but none will help you write a better, more maintainable program. Regards, Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
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! -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On 21/11/2022 01.29, Stefan Ram wrote:
dn 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
--
https://mail.python.org/mailman/listinfo/python-list
Re: Passing information between modules
On Mon, 21 Nov 2022 at 16:26, dn 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 -- https://mail.python.org/mailman/listinfo/python-list
