Menu
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.
264
I try to adhere to the style guide for Python code (also known as PEP 8). Accordingly, the preferred way to name a class is using CamelCase: Almost without exception, class names use the CapWords convention.
Package and Module Names Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
Python logging basicConfig The basicConfig configures the root logger. It does basic configuration for the logging system by creating a stream handler with a default formatter. The debug , info , warning , error and critical call basicConfig automatically if no handlers are defined for the root logger.
As mentioned, PEP 8 says to use lower_case_with_underscores for variables, methods and functions.
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.
152
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
