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_CONFIG = None
Essentially they enforce my logging config and prevent Django from interfering.
I’ve never managed to get results I understand with any other technique.
Likely I could figure it out, given enough time, but until now I haven’t.
--
Aymeric.
> On 06 Sep 2016, at 07:52, Ivan Sagalaev <[email protected]> wrote:
>
> Hello everyone,
>
> It's been a while since I last posted here, please forgive if I break any new
> rules inadvertently.
>
> I'd like to revisit a decision made in [18993][]. My use case is very simple
> and obvious: I want all logging going into stdout.
>
> As currently implemented, I can't do it easily with a custom `LOGGING`
> setting, because:
>
> - If I leave existing Django loggers enabled it ties me to the behavior
> chosen by Django, which doesn't necessarily match what I want. For example,
> Django won't log debug and info messages if `DEBUG = False`. And with `DEBUG
> = True` I will be having two log messages for every log into the 'django'
> logger: one from the Django's own handler, and another after it propagates to
> my root logger.
>
> - If I disable existing Django loggers, I effectively disable all logging
> from Django (and from 'py.warnings' for good measure).
>
> In fact, the idea of providing a default logging configuration which a user
> can then *build upon* isn't really workable with Python logging: you can
> either fully reuse or fully discard what's been provided, but you can't
> meaningfully define a consistent configuration. Also, I have my doubts that
> this "build upon" use case is based on any real demand. In my experience
> there are only two approaches to configuring logging: "logging? huh, didn't
> think about it" and "get your hands off my logging, I know what I'm doing!"
>
> The latter, incidentally, is what the old way was doing: define a sensible
> default value for `LOGGING` and let users to overwrite it completely.
> Currently, the default logging configuration is hard-coded in
> `django.utils.log`.
>
> Also, I couldn't find the actual reasoning for the current behavior in the
> original ticket. It starts talking about having a more useful default, not
> about changing the way how this default configuration is applied.
>
> [18993]: https://code.djangoproject.com/ticket/18993
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/django-developers
> <https://groups.google.com/group/django-developers>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/57ca68fd-214a-4fe4-b759-7fc8cb597b35%40googlegroups.com
>
> <https://groups.google.com/d/msgid/django-developers/57ca68fd-214a-4fe4-b759-7fc8cb597b35%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/A856D036-644D-4485-ADE8-9AE2629ACD22%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
