I am refactoring some code and I would like to get rid of a global
variable. Here is the outline:
...
I have never done that in Python because I deliberately avoided such complicated situations up to now. I know about the Singleton pattern,
but I have never implemented it in Python and I don't know if it is Pythonish.
Hello,
I am refactoring some code and I would like to get rid of a global
variable. Here is the outline:
import subprocess
CACHE = {}
The global cache variable made unit testing of the lookup(key) method
clumsy, because I have to clean it after each unit test. I refactored
it as:
class Lookup:
def __init__(self):
self.cache = {}
On Tue, 12 Mar 2024 at 07:54, Ivan "Rambius" Ivanov via Python-list <python-list@python.org> wrote:
I am refactoring some code and I would like to get rid of a global variable. Here is the outline:
...
I have never done that in Python because I deliberately avoided such complicated situations up to now. I know about the Singleton pattern,
but I have never implemented it in Python and I don't know if it is Pythonish.
A Singleton is just a global variable. Why do this? Did someone tellI have bad experience with global variables because it is hard to
you "global variables are bad, don't use them"?
Good question Rambius!
On 12/03/24 09:53, Ivan "Rambius" Ivanov via Python-list wrote:
Hello,
I am refactoring some code and I would like to get rid of a global variable. Here is the outline:
import subprocess
CACHE = {}
First thought: don't reinvent-the-wheel, use lru_cache (https://docs.python.org/3/library/functools.html)
The global cache variable made unit testing of the lookup(key) method clumsy, because I have to clean it after each unit test. I refactored
it as:
class Lookup:
def __init__(self):
self.cache = {}
Change "cache" to be a class-attribute (it is currently an instance.
Then, code AFTER the definition of Lookup can refer to Lookup.cache, regardless of instantiation, and code within Lookup can refer to
self.cache as-is...
A Singleton is just a global variable. Why do this? Did someone tell
you "global variables are bad, don't use them"?
I have bad experience with global variables because it is hard to
track what and when modifies them. I don't consider them bad, but if I
can I avoid them.
I am refactoring some code and I would like to get rid of a global
variable. Here is the outline:
The global cache variable made unit testing of the lookup(key) methodk=3DFalse)
clumsy, because I have to clean it after each unit test. I refactored
it as:
=20
class Lookup:
def __init__(self):
self.cache =3D {}
=20
def lookup(key):
if key in self.cache:
return self.cache[key]
=20
value =3D None
=20
cmd =3D f"mycmd {key}"
proc =3D subprocess(cmd, capture_output=3DTrue, text=3DTrue, chec=
if proc.returncode =3D=3D 0:[...]
value =3D proc.stdout.strip()
else:
logger.error("cmd returned error")
=20
self.cache[key] =3D value
return value
=20
Now it is easier to unit test, and the cache is not global. However, I
cannot instantiate Lookup inside the while- or for- loops in main(),
because the cache should be only one. I need to ensure there is only
one instance of Lookup - this is why I made it a global variable, so
that it is accessible to all functions in that script and the one that actually needs it is 4 levels down in the call stack.
I am looking for the same behaviour as logging.getLogger(name). logging.getLogger("myname") will always return the same object no
matter where it is called as long as the name argument is the same.
=20
How would you advise me to implement that?
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 920 |
Nodes: | 10 (1 / 9) |
Uptime: | 85:10:04 |
Calls: | 12,188 |
Calls today: | 3 |
Files: | 186,526 |
Messages: | 2,237,067 |