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
🔧 Tweak/adjust the logging verbosity greater-eq to warning level #147
Conversation
Note for those who will stumble upon this PR. You may find your recent discovery unexpected and/or unpleasant but you have to understand that in any context, Actually, your discoveries demonstrate that we clearly cannot drop that kind of dependency in a short term. |
That's better, but IMO it should be all DEBUG level. Is there any use case for these log messages other than debugging (in which case DEBUG is perfect)? In normal operation charset_normalizer should generally just stay out of the way and return the the results to the code. Example of a specific use case: In my program the default log level is INFO, so I set |
I will not revise the logging level to debug for everything. Historically and still used for readability purposes. I agreed with lowering WARNs. Until the next major no modifications are planned.
You already have a good workaround solution. |
Yes, but that means if I want to debug an issue with charset_normalizer then I'll have to go into my code and re-enable logging for it because I'll have it disabled even in debug mode. Oh well. I don't quite understand what you mean with this sentence: "Historically and still used for readability purposes". I can only see one DEBUG level message emitted by charset_normalizer right now and it's quite short too, so I doubt anyone would complain that they're going to be forced to see 1 short message in addition to the current 4 longer ones. So far I haven't heard a convincing argument for why it needs to be separated this way, especially with there being more INFO messages than DEBUG, when it's generally the other way around. But of course you don't owe me anything and you're free to disagree, I would just prefer if there was a logical explanation for it. |
I understand but I am not willing to make changes right now. You will have to compromise.
When one spent as many hours as I spent on this package, I just need the logging to be delivered as is to ease my job as a solo maintainer. Your issue is marginal and I can't say yes to everyone and dismiss my own sanity (among others) in the process. |
I'm sorry if I came across as demanding, I simply suggested it because to me it seemed like a logical thing and not just a personal preference. You don't have to, but it would certainly help me understand more if you explained why the current setup benefits your workflow. As an outsider it doesn't seem logical to me but I could very well be missing something, but unfortunately I can't read your mind. Sure, you could argue that I shouldn't be enabling logs from all libraries, but like I said I only enable them in debug mode, where I specifically want to receive debuh logs from libraries as well (especially urllib3). That doesn't mean I want them all lumped together as an unreadable mess in a single color though. This is definitely not the only library I've encountered that uses INFO for messages I consider useless at that level, but it's in the minority. Anyway, I've found a better solution to my problem. I monkey-patched |
I understand that the latest release unexpectedly generated some noise for some people in specific environments.
The engagement I made with
charset-normalizer
given its wide deployments* still applies. Therefore, regarding :With this PR I adjust the impact to a minimal impact while keeping backward compatibility.
Fixes/Adress #145
*: Listening as broadly as possible regarding any side-effects to the community