On 31/08/2022 05.26, Schachner, Joseph (US) wrote: > The way we do this, is in main.py, call a "globalizer" function in each other > file: > > # call globalizers to get shortcuts as global variables > funcs.globalizer(interface, variable_dict) > util.globalizer(interface, variable_dict) > sd.globalizer(interface, variable_dict) > tests.globalizer(interface, variable_dict) > ut.globalizer(interface, variable_dict) > > Obviously, you may not need a shared interface in which case you can just > pass the variable dictionary. > > In each file, you have a function: > def globalizer(interface, variables_dict): > # create global variables for this .py file for shared interface and the > variables > .... > > This works well, making sure separate python files shared exactly the same > things we want to be global. > > ---- Joseph S. > > Teledyne Confidential; Commercially Sensitive Business Data > > -----Original Message----- > From: Stefan Ram <r...@zedat.fu-berlin.de> > Sent: Tuesday, August 30, 2022 1:09 AM > To: python-list@python.org > Subject: Re: How to make a variable's late binding crosses the module > boundary? > > dn <pythonl...@danceswithmice.info> writes: >> Build module.py as: >> *** >> CONSTANT = 1 > >> def func(): >> pass >> *** > >> then in the terminal: >> *** >> Python 3.9.13 (main, May 18 2022, 00:00:00) [GCC 11.3.1 20220421 (Red >> Hat 11.3.1-2)] on linux Type "help", "copyright", "credits" or >> "license" for more information. >>>>> from module import func as f > > In CPython one then can also: > > print( f.__globals__[ "CONSTANT" ]) > import sys > module = sys.modules[ f.__globals__[ "__name__" ]] print( module.CONSTANT ) > CONSTANT = module.CONSTANT print( CONSTANT )
The conversation seems to be wandering some way from the OP. Whereas both of these answers are clever (and I assume work), the question becomes: why would you want to do this? (especially as it looks ugly and 'smells' a bit convoluted). An example use-case from your experience? Delving into the list-archive, to get back to the OP: the first message in the thread quotes another message that's (apparently) not present. However, in there somewhere is: > from test import * So, the elephant-in-the-room has always been a very stinky 'code-smell' - which pretty much every text or web-tutorial will say is a bad idea. Why is a bad idea? Why is it there then? When to use it? [Socratic questioning] Same question, but the other way around: why has Python been equipped with modules, classes, functions, etc? To quote The Zen of Python: "Namespaces are one honking great idea -- let's do more of those!". Programming paradigms and architectural principles all contain reference and recommendation to independent code-units, coupling and cohesion, boundary crossing and interfaces (etc). Python doesn't enact a formal interface construct (thank you great, high, Python, gods!), but that doesn't remove the issues behind them (as the OP-code demonstrates). Instead it requires a Python-idiomatic approach. Should the question be: "how to I smash two namespaces into one and have it work 'my way'?", or should the question become "how does Python enable passing/retention of values between namespaces?". NB The OP likely reduced the 'problem' to 'minimum-code' for the benefit of the list, but what is the motivation behind it? Why would one want to be able to do this? Rationale? Use-case? Enquiring minds and all that... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
