I just recently discovered that there's no documented way to dump the current configuration (https://stackoverflow.com/q/72624883) so you can see what loggers exist and where their output is going.
When running a webserver though, an even simpler trick is to add middleware that sets the current request's info as the current thread's name, and then including threadName in your log format.
[1] https://docs.python.org/3/library/logging.html#logging.Logge...
I had mistakenly assumed ContextVars only worked for async code.
Overall, I prefer less magic and more explicitness.
It has a bit of an initial learning curve, but once you understand how fixtures work it's amazing how productive you can be with it.
I might be in the minority but I also find python's mock implementation awful. Mockito in Java is way better where you explicitly state which calls you expect and if you get an unexpected call it errors out.
Also with improvement of type hinting, tooling like PyCharm starts to understand pytest better and make it easier to read and manage and a lot of the magic can be dispellt by written out explicitly. Though this need some discipline from the dev team.
By “Java written all over it” do you mean that like JUnit for Java, it's an implementation of the xUnit pattern derived from SUnit for Smalltalk?
So, it's maybe not the best evidence that the Python version is particularly a clone of the Java port.
Pytest is very opinionated about how and when it's going to be run. If you want to put a test in say, Jupyter or a Markdown block, unittest is much more amenable to just doing what you want without having to read through documentation to break a whole bunch of magic behavior.
And regarding the sibling comment: Yes, I prefer unittest as well.
The irony is Java logging moved on and with newer libraries offers better supports for lazy evaluation, structured logging and multiple output formats, while Python logging seems stuck with an ancient copy of log4j 1.x
That sounds like there's a Log4shell-like vulnerability waiting to be found. But I couldn't even find it, I found the SocketHandler but that's just a log destination.
EDIT: shockingly, I did find it: https://docs.python.org/3/howto/logging-cookbook.html#config...
But IMO it inherited most of loggers problems while not offering a better interface
It is basically a kwargs to json or 'key=value' converter
(Also json logs are overrated. There I said it. Especially one key per line, please don't)
You need good quality logs though. Because noisy useless JSON logs are even more noisy and useless.
Agreed on the one key per line bit.
Sadly, my social media is subscribed to by pretty heavy hitters in the Python community, but when I asked about the best logging for python it was all crickets. Maybe that says something. :-)
print(f"log_func: {var_a} not found!")Presumably these levels derive from syslog or older. I've no idea why they omitted NOTICE.
Also logging can be set up remotely, but it's easier to do like that from the container and then configure the hos to send everything to a single log machine.
https://github.com/Delgan/loguru
Also iirc s3's "file-like interface" does not actually obey the file protocol, which is obnoxious.
Those are just println() and eprintln()
It's literally easier to just have an IOBuffer laying around.
https://docs.python.org/3/library/logging.html#logging.Logge...
For dictConfig, the documentation has examples
https://docs.python.org/3/library/logging.config.html#object...
Python's logging has its faults, but you're complaining about something I could find in 5 minutes of Google.
Each module should use `logger = logging.getLogger(__name__)` and the logger config can set in one place, conventionally in the `__main__` script.
https://docs.python.org/3/howto/logging.html#advanced-loggin...
One has to remember that logging was never intended to be some infinitely generalizable metaprotocol for massively streaming parallel notifications to the cloud or whatever. It was meant as a replacement for "if (DEBUG > 4): print(...)". For which I think it does quite well, thank you.
The whole library is just really rubbish and has not aged well. Hate it.
So what have you written that has made people's (not just your bosses' or your clients') lives easier, for nearly 20 years now (if only incrementally)? Do share.
I see and grant your points, but I find this strong emotional rebuke of something that was never intended to be anything more than a simple convenience library to be well, strange.
So now everything needs to work with it, it’s internals and it’s way of doing things. And to top it off it’s near impossible to refactor or replace.
Things I really dislike about it is the lack of “context”. Usually log messages are about something - often a request. You can’t attach a request ID or something else a nested set of function calls that log.
The whole library is just really rubbish and has not aged well. There’s no standard way of outputting JSON logs, but there’s a built in way to spawn a socket server that allows the logging configuration to be updated remotely via a bespoke protocol? And everything is built mostly around logging to files.
It also hits that perfect sweet spot of being both overly engineered and totally inflexible. I wanted to funnel our log messages to s3 via the “s3fs” module, which supports a “file like” object that gets written to s3. I had to hack around the various handlers to support this because it assumes it’s a “real” file.
Hate it.