On Sat, Mar 27, 2021 at 6:01 AM Patrick Riehecky <riehecky@fnal.gov> wrote:
Hello,
I've been chasing down various synchronization bugs in a large codebase I'm working on.
In the process I began to realize how useful it would be to have some sort of descriptor (a name if you will) attached to some of my primitives.
In this code base, I've a number of threading.Event objects that get passed around to check for conditions. In a perfect world, every developer would have used the same nomenclature and been consistent everywhere. Alas....
Currently there isn't a great way built into the language for me to say "which Event is this <threading.Event object at 0x7f66da73ed60> ?" unless I already have a mapping of the addresses to variable names in my logs.
Would a `name=` keywordonly argument for things like Lock, Event, Condition, Barrier, Semaphore, etc be welcome (for threading, multiprocess, async, etc)?
Sounds like a good idea. Threads themselves have that feature, although I seldom actually use it. But it's great to have available.
Inside the code base, such an attribute would let me do things like:
mycondition.wait() print(f'Met condition {mycondition.name}')
or
print(f'Waiting on barrier {mybarrier.name}') mybarrier.wait()
And similar.
You can already do this, although without the keyword arg. You can simply attach attributes to these objects. It's a quick-and-dirty way to achieve your goal, but it doesn't require you to wait till you can move to a new Python version :) +1, this seems like a useful feature in some situations and not problematic where it's not needed. ChrisA