I read Naming Conventions in PEP 8 – Style Guide for Python Code.

And, it says:

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

Next, I read threading — Thread-based parallelism.

And, it says:

Note: In the Python 2.x series, this module contained camelCase names for some methods and functions. These are deprecated as of Python 3.10, but they are still supported for compatibility with Python 2.5 and lower.

So, is camelCase basically deprecated or not allowed to use in Python?

CodePudding user response：

First of all, let's clarify:

CapitalizedWords (or CapWords, or CamelCase).

mixedCase (differs from CapitalizedWords by initial lowercase character, as in your case you wrote 'camelCase')

Now, some confusion arises with older Python 2, but the most recent Python 3 versions, follows a more pythonic way using the PEP convention, and:

Class names should normally use the CapWords convention.

And, Function names should be lowercase, with words separated by underscores as necessary to improve readability (aka snake_case).

Variable names follow the same convention as function names.

Constants follow UPPERCASE

CodePudding user response：

In Python you're free to name variables however you'd like. This means that declarations in camelCase will be accepted by the interpreter just fine.

However the Python community has agreed that snake_case should be used for functions and variable names, and CapCase should be used for class names. In general it's better to follow these guidelines to make your Python code more easily readable, even though it is not required by the Python interpreter.

There are some cases where camelCase became the prevailing convention for naming variables, often when a library was ported over from another language where camelCase is preferred. One such example is pyQt, which is ported from C (here's an example from their docs). In these cases it's more important to be consistent than conformant, so it's preferred if you stick with the same style for the whole codebase.