Do we want to name this class as opencensus.metrics.GaugeRegistry or opencensus.metrics.gauge.Registry? opencensus.metrics.Registry is a very generic name.

That makes sense, gauge.Registry works for me.

Depending on whether it is CPython or something else, we might not need the threading.Lock while getting values().

What about if another thread changes a value while we're iterating here? E.g.

import time
from concurrent.futures import ThreadPoolExecutor

tpe1 = ThreadPoolExecutor(max_workers=1)
tpe2 = ThreadPoolExecutor(max_workers=1)

dd = dict(zip(range(10), range(10)))

def read_values():
    global dd
    for vv in dd.values():
        print(vv, end=", ")
        time.sleep(.01)
    print()
        
def mess_with_values():
    global dd
    for kk in dd:
        dd[kk] = -dd[kk]
        time.sleep(.01)


tpe1.submit(read_values)
tpe2.submit(mess_with_values)

0, 1, 2, 3, 4, -5, -6, -7, -8, -9, 

I think there are better ways to do this, all the locking in gauges so far has been pretty naive. One obvious improvement is to use a read/write lock to let more than one thread read at once. I didn't spend time optimizing this yet because I don't think we're likely to have a bottleneck here, but I did want to make sure the class was threadsafe.

I thought we are only adding new gauges (add_gauge) instead of altering the existing gauges?
And after we take a snapshot of the registered gauges, we get the metrics based on a pre-calculated value now.

I thought we'd want to remove gauges too, but after talking to @bogdandrutu it turns out that this is by design.

Looking more closely at dictview I think you're right that we don't need a lock here.

Is there a preference over set than tuple?

No preference, just to emphasize that it's unordered. The java client returns an ArrayList but the order isn't fixed.