Can you explain the weird and inconsistent naming of functions in Python base libraries?

Question

When I started learning Python I started loving it for how much more structured it was than PHP which has a lot of functions that do not mentally flow very well, but I've been noticing odd inconsistencies with no apparent reasoning in Python as well.

For example, in PHP there are some functions for arrays that start with "array" in their name, some that don't, some that use underscores, some that shorten parts of their names down to a single character, etc. and they typically need to take an array as an argument rather than being a method of an array object.

In Python, there are a lot of single-word function names, but when it comes to multiple words I see an inconsistency.
For example, logging module methods with camelcase like logging.StreamHandler(), underscores in sys like sys.base_prefix() and just lower case with no separators like os.expandvars().
As if that wasn't enough, there are function names like os.path.splitext() that eventually led to me posting this.

Why are they not all one type of convention?

logging.StreamHandler() # capitalize in case classes
sys.basePrefix()
os.expandVars()
os.path.splitText()

or even like this:

logging.stream_handler()
sys.base_prefix()
os.expand_vars()
os.path.split_text() # the original is actually "spli + text" in one word!

Is there any popular programming language out there that strictly adheres to conventions like in my example below?

some_value        # variable lower case separated by underscores (which allows them to appear descriptive)
someFunction()    # functions and methods camel case, first letter lower case (differentiates from variables while still readable and allows simple names like get() and send())
SomeObject()      # classes always start with capital letters and are camelcase (makes them stand out and above but appear closer to functions)
IMPORTANT_VALUE   # constants always upper case, separated by underscores (easily tell apart from anything else, while being the reverse case from normal variables)

So why does this happen and does something like my example ever happen to a significant extend in reality?

Answer 1

Part of the reason for these inconsistencies come about because Python developers value consistency within a single module as more important than consistency with the rest of the standard library.

As to why the modules within the standard library have varying naming conventions, many of these came about because of many reasons. The os module for example, most of the functions there are straightforward wrappers around function with the same name in C standard and system/POSIX libraries; to reduce friction between C and Python developers and to take advantage of developer's existing knowledge of POSIX, the C names have simply been used as-is for that module. There are functions in the os module that doesn't have a correspondence with C/POSIX functions, but to avoid internal inconsistency within os module, they also inherit the C naming convention.

If you want a more Pythonic version of the standard library, there are higher level wrappers for many of the functions in os, such as subprocess module and pathlib. These modules follow the PEP8 naming convention.

PEP8 specifies that classes are named with CamelCase and variables, functions, and attributes are named with snake_case, that explains the difference between logging.StreamHandler and sys.base_prefix.

And then there are libraries like XML/HTML DOM, which specifies function names that adheres more to JavaScript naming convention (XML and HTML DOM API were designed by the web standards people, which follows the tradition of JavaScript), or unittest which is designed based on Java's xUnit. Python decided to just adopt those existing naming conventions to exploit familiarities with people who are already familiar with the existing names, as the API are simply copied as-is.

then decide to omit a letter for English words here and there

Most of the function names with omitted letters usually come from ancient C libraries, these were named back when text editors weren't as advanced and people want to save letters to minimise typing long variable names or when there are restrictive character limits on how long you can name things. Python and PHP inherit many of these names for the low level wrappers for these functions.

Python is often used as a glue language, which means it is often used to put together an application from libraries written in other languages, which has their own existing naming conventions. Renaming these established interfaces just to conform to Python's naming convention will just confuse people who are familiar with the established APIs for no good reason, as consistency with the established APIs are more important when reading documentations, while consistency with the rest of the standard library are pretty much just for aesthetics.