Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I'm confused about MeterStatDict #11

Open
NorthIsUp opened this issue Feb 29, 2012 · 3 comments
Open

I'm confused about MeterStatDict #11

NorthIsUp opened this issue Feb 29, 2012 · 3 comments

Comments

@NorthIsUp
Copy link
Contributor

This is mainly about naming things, but tell me if I'm way wrong on this.

So I have the following stats:

STATS = scales.collection('/api',
    meter.MeterStat('api_v1'),
    meter.MeterStat('multiplexed'),
    scales.IntDictStat('status_code'),
    scales.PmfStat('latency'),
    )

I can go STATS.status_code[200] += 1, but what I really want to do is have a default dictionary of meters so I could do STATS.status_code[200].mark(), but MeterStatDict doesn't seem to be anything like IntDictStat.

Can somebody explain/document the thoughts behind some of these data structures?

p.s. you guys going to py con? I'd love to meet up.

@PeterScott
Copy link
Member

From looking at the code -- and I didn't write this part, so don't quote me on this -- it looks like MeterStatDict is part of the internal workings of MeterStat, and not meant to be used directly. The best workaround I can think of here is to create a bunch of MeterStats, one for each HTTP status code. I'm sure there's a way to do this automatically (see "Class Stats" in the readme for my best guess as to how), but there's a lot of magic in the scales internals, and I forget how most of it works.

If you do end up making something like a default dictionary of meters, that would be really cool.

@NorthIsUp
Copy link
Contributor Author

As MeterStatDict is internal, I may submit a patch re-naming it to avoid confusion. Something like _MeterStatImpl. Or something.

@PeterScott
Copy link
Member

That sounds reasonable; just adding the leading underscore could help. Of course, there are a bunch of other classes whose names could use changing like that, such as IntDict, which is internal to IntDictStat.

In general, I wish that scales had more documentation. It's also due for a code cleanup one of these days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants