I have heard developers who try to make their coding achievements sound more complex than they really are. I've never heard anyone admit this, but I have seen code that meets your criteria that was created intentionally out of haste or poor practices and not sabotage. The code surrounding the maligned code may have been altered to the point where a particular function is no longer useful.
Someone would actually have to see this code first-hand before coming to the conclusion that only this developer can manage the complexity. Most managers and other business people just come to this conclusion because they don't understand any kind of code and don't want to refill the position.
Articles in Variable Names
They add little to no value in most cases, but make the code longer to read.
Usually, I'd rarely have a the need for the distinction between a "a" or "the" in the flow of a function, so it doesn't make sense to use articles.
It's a formal programming language and I am fine with it not reading exactly like a natural language. In fact, it's probably better this way, not everything's necessarily so great about natural languages.
There are a few cases where readability can benefit from using articles though, for instance if you want to implement a checker for a "is a" relationship with a method signature like boolean isA(Object o, Class<?> cl) (I'm not advocating this to be a good idea).
Hard-Coded Strings
It depends on whether you plan to reuse them or not, and whether that reuse is driven by semantics (and not just the fact that the String has the same content in different places) and spread across multiples classes or sub-systems.
To that extent, I usually use these rules:
If you have the same string multiple times and it has the same meaning acros multiple classes, then extract to constants in an interface.
If you have the same string multiple times within a single class and it has the same meaning within that class, then extract to constants within the class.
If you have only a few number of repetitions of as tring, or they just happen to be identical but aren't guaranteed to always be in the future, then I'd leave them inlined.
If any of the above would render maintenance difficult, screw rules 1 to 3 and do whatever works best for you.
Of course, make sure that the constant's name makes the code as semantically valid as the string it holds. That also applies for other things that aren't strings (like Predicates, for instance).
Best Answer
Quoting https://www.python.org/dev/peps/pep-0008/#package-and-module-names:
For classes:
And function and (local) variable names should be:
See this answer for the difference between a module, class and package:
So PEP 8 tells you that:
PEP 8 tells that names should be short; this answer gives a good overview of what to take into account when creating variable names, which also apply to other names (for classes, packages, etc.):
To finish, a good overview of the naming conventions is given in the Google Python Style Guide.