I had troubles understanding the logging setup the first time, but after
that, its quite simple on every project. I usually end up copy/pasting some
console and db logger class and just add it to the config, I don't really
think it is that difficult
El martes, 6 de septiembre de 2016, 9:57:16 (
On 09/08/2016 11:31 PM, Ivan Sagalaev wrote:
> I'm not familiar with the current deprecation policy in Django. If you
> can point me to it, I could probably carve some time in the nearby
> future and prepare a pull request.
Here is the deprecation policy:
https://docs.djangoproject.com/en/dev/inte
Le vendredi 9 septembre 2016 07:31:42 UTC+2, Ivan Sagalaev a écrit :
> I think the best end result would be one where LOGGING simply defines the
>> full config and it is always applied (by Django) exactly once, and the
>> defaults we want are set as the global default for LOGGING, and just
>>
>
> It sounds like you are maybe proposing to decide whether to pre-initialize
> logging with the built-in default config or not based on whether the user's
> LOGGING setting has disable_existing_loggers set to True or False?
>
Yes, I was thinking on my feet and this was one idea I came up with
Hi Ivan,
> On Sep 8, 2016, at 9:00 PM, Ivan Sagalaev wrote:
>
> Actually… I'm failing to imagine a scenario where such a change would lead to
> any bad things:
You may be right, but it's hard to evaluate that without knowing precisely what
change you are envisioning. Can you be more specific
Actually… I'm failing to imagine a scenario where such a change would lead
to any bad things:
- If `disable_existing_loggers` is True, the incompatibility would manifest
itself in Django loggers not being silenced, provided the user has defined
a root logger. Which is probably the intended beha
Carl, I think this is the thread with your past comments:
https://groups.google.com/d/topic/django-developers/no2IhnRty68/discussion
To avoid a new setting, we could add some custom key/value to LOGGING for
the new behavior and pop it before the dict is passed to dictConfig.
On Tuesday, Septemb
On 09/06/2016 04:57 PM, Ivan Sagalaev wrote:
> I'm
> talking about this function:
> https://github.com/django/django/blob/master/django/utils/log.py#L66
>
> When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally
> initializes logging with the hard-coded configuration and then app
>
> Just to be sure, which version of Django are you using? There were some
> simplifications in Django 1.9 that attempted to make writing custom logging
> configurations easier and further changes in Django 1.10.
>
I'm using 1.9, but I'm referring to the code in master.
>
> https://github.
>
> It’s unclear to me as well how the current system is intended to be used.
>
I can speculate, that the idea was that you *can* disable the existing
loggers and define your own, but the effect of it actually disabling all
logging from Django instead of it falling through to the custom root lo
Just to be sure, which version of Django are you using? There were some
simplifications in Django 1.9 that attempted to make writing custom logging
configurations easier and further changes in Django 1.10.
https://github.com/django/django/commit/8efea1b8d5b5fb0cfef1a3244c339cebf8af36c5
https://g
It’s unclear to me as well how the current system is intended to be used.
All my projects do this:
> # Configure logging manually to avoid merging with Django's defaults.
>
> LOGGING = {
> # custom logging configuration goes here
> }
>
> logging.config.dictConfig(LOGGING)
>
> LOGGING_CONFI
12 matches
Mail list logo
