On Jun 15, 2013, at 5:28 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:

On 06/15/2013 12:13 PM, Glyph wrote:

I am really, really puzzled by this reaction.  I am wondering if you
read my message carefully, or if I didn't express myself well.

Careful re-reading of the very last bit of your message suggests I may have misunderstood.

OK, whew :).

I think I understand the "final" stage, and in that situation the UUID is invisible, correct? It's hidden behind the declaration of a "log event" object which can be called to emit or observe said events.

That's right.

That seems fine, though I'm not sure what the UUID *does* in that situation - route/match is via python object access, no?

What it does is it allows *older* monitoring scripts to work.  It also holds on to the UUID internally so that if, for example, the module's name is changed in the future, the API name can be re-named and code can be pointed at it via the normal deprecate/redirect mechanism.  (Of course, _any_ sort of explicit / unique identifier would work for this latter use-case; it's just that this one has the benefit of not visibly containing the string that has now been changed, and so there's no long-term impulse to "clean it up" further and thus break stuff.)

I *think* I now understand the intermediate stage, where the log events are emitted by old code, and observed by UUID. You're suggesting calculating the UUID from the module name and static data (format string). I guess that's no worse than any other solution - until the log emitter is converted to a newer/better API, there's no great way to observe it.

Before we proceed, can you confirm I've understood your proposal correctly?

Sounds like you've got it just about right now.

-g