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