Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#27691 closed Uncategorized (invalid)

Avoid `logger=logging.getLogger(__name__)`

Reported by: Thomas Güttler Owned by: nobody
Component: Uncategorized Version: 1.10
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The current docs suggest this:

# import the logging library
import logging

# Get an instance of a logger
logger = logging.getLogger(__name__)

Source https://docs.djangoproject.com/en/dev/topics/logging/#using-logging

I don't like it. But I like the optimize-Imports feature of PyCharm, and the following line (often between the imports) disturbs this.

Is there no way to avoid this logger = logging.getLogger(__name__) ?

I asked this question some time ago at StackOverflow: http://stackoverflow.com/questions/34726515/avoid-logger-logging-getlogger-name

It would be very nice if this would be enough: import logging .... logging.warn(...). But with the semantics of logger = logging.getLogger(__name__).

Change History (3)

comment:1 by Simon Charette, 8 years ago

I don't like it. But I like the optimize-Imports feature of PyCharm, and the following line (often between the imports) disturbs this.

Is there a reason you can't instantiate the logger after all of your imports instead of in the middle of them?

Is there no way to avoid this logger = logging.getLogger(name) ?

I don't think so if you want to create a namespaced logger. If you don't mind logging all of your messages in the root namespace and relying on a formatter to describe their origin nothing prevents you from doing it (by using logging directly) but I don't think it's a practice we should encourage as the main strength of the logging framework lies in per-namespace routing of messages.

From my experience the more complex your application gets the more it will require namespaced logging messages. It's also a hard requirement if you're writing any kind of third-party applications.

Version 0, edited 8 years ago by Simon Charette (next)

comment:2 by Tim Graham, 8 years ago

Resolution: invalid
Status: newclosed

Please ask questions like this on TicketClosingReasons/UseSupportChannels (although this is a question about how Python logging works, not really Django-specific, I think).

comment:3 by Thomas Güttler, 8 years ago

Just for the records: This issue is about what the django docs should look like.

Note: See TracTickets for help on using tickets.
Back to Top