A newer, better thread-local API #225
Conversation
… NOT return distinct values if you call it from separate python threads. Also reformat.
|
I'm not sure why coverage isn't working. My tests should be covering everything 100% and I don't understand how to read the output of codecov.io |
|
This should be helpful: https://codecov.io/gh/hynek/structlog/src/222-thread-local/src/structlog/threadlocal.py#L178 Maybe you call clear before or something? That said, could you make them both a try/except block? I'm not a fan of hasattr in my codebases. Other that that, it looks super promising. When people asked me about support contextvars, something exactly like this came to my mind. Since the code is rather trivial, I suppose it doesn't make any sense to try to make something generic? It's definitely the better approach than having everything global by default and offer temporary binds. |
|
OK cool. Do you need anything from me to finish this up? If you want, you can skip narrative docs for now. I can write them in a separate PR and you'll review it (timely! 🤪). But please refer to CONTRIBUTING.rst, there's a bunch of transgressions. :) |
|
@hynek I already started on the docs when I saw your message, so I figured I'd finish up what I have and put it up here. Please let me know which contribution guidelines I have missed. |
…owcase structlog.configure so I'll do that.
src/structlog/threadlocal.py
Outdated
|
|
||
| def merge_threadlocal_context(logger, method_name, event_dict): | ||
| """ | ||
| A structlog processor that merges in a global (thread-local) context. |
CHANGELOG.rst
Outdated
| @@ -51,7 +51,9 @@ Changes: | |||
| So far, the configuration proxy, ``structlog.processor.TimeStamper``, ``structlog.BoundLogger``, ``structlog.PrintLogger`` and ``structlog.dev.ConsoleLogger`` have been made pickelable. | |||
| Please report if you need any another class ported. | |||
| `#126 <https://github.com/hynek/structlog/issues/126>`_ | |||
|
|
|||
| - Added a new thread-local API that allows binding values to a thread-local context explicitly without affecting the default behavior of bind. | |||
|
Thanks for the review @hynek, I've addressed your requests. |
|
Thanks Chris, please come back soon! ;) |
Fixes #222
caveat: I didn't duplicate the greenlet support because it turns out greenlet.getcurrent() doesn't seem to return separate objects for different OS-level Python threads. That means that if you somehow have
greenletin your dependency tree, the existing thread-local stuff will just straight up not work.If someone cares I'm sure it'd be possible to implement something that uses greenlets and threadlocal in a way that ensures that you get distinct values in different greenlets AND distinct values in different python threads.