How come the Python's logging module doesn't follow PEP8 conventions?

Question

This is is just a curiosity with historical purposes:

I was wondering if someone knows why the very widely used (and core module) logging doesn't follow the Python's PEP-8 naming convention.

For instance, in

>>> import logging
>>> log = logging.getLogger("hello")

I would expect it to be get_logger, but it isn't.

When it comes to function names, the PEP8 standard says:

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

Was that the case? If so, with what other logging thingy it had to maintain backwards compatibility? Or was it just that the developers of logging felt like using camel-case naming?

Of course, the module is well documented and is not a big deal at all. I'm just curious.

Answer 1

The logging module was developed by a separate company in 2001, and was heavily based on Log4j. As such it follows the naming conventions the original author picked, which mirror the Log4j choices; the latter has a getLogger() method too.

Not until a year later did PEP 282 propose to add it to the standard library, by which time the naming convention was set in stone.

It is a known issue with the package, but it is not the only package to violate the PEP. From the linked Wiki:

PEP8 says - consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

• So True, but can't not be changed, because of backward compatibility. logging2 maybe. -- techtonik
  • It's a low priority right now, unless there's an initiative to ensure the rest of the stdlib is made to conform to PEP8. -- VinaySajip

Last but not least, the styleguide itself has this to say on applying styleguides:

A Foolish Consistency is the Hobgoblin of Little Minds

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

In particular: do not break backwards compatibility just to comply with this PEP!

'Fixing' logging would break backwards compatibility, which is just not worth it.