This is mainly related to Pyblish FTrack which currently uses a mix of
mixedCase but is something capable of happening elsewhere too where one or more libraries you depend on isn’t following PEP08, such as the ftrack API and PyQt.
Consistency is important, but in these situations, what should (and can) we do?
I see two possibilities. We can either stick to convention on a module-to-module basis, in which case a module that uses a library with
mixedCase also adapts to using
mixedCase. The other possibility is to stick to writing your code in PEP08, and limit other conventions to where it is impossible to do otherwise.
With this approach, the question is, what happens if you use two libraries with different conventions - one with
mixedCase, one with
CamelCase and one with
And perhaps more importantly, with this approach you loose any form of convention across multiple modules, within or between packages.
import nonPEP8 def myFunc(arg1, arg2): return nonPEP8.someFunc(arg1, arg2)
def my_other_func(arg1, arg2): return True
In this case, a mixture of PEP8 and non-PEP08 is embraced and used to it’s advantage.
One benefit of keeping with a consistent naming convention for your code and leave other libraries be is that you gain a clear separation between what is theirs and what is yours.
class Manager(unknown.Object): def some_func(self, argument): self.dispatchRequest(argument) def otherFunc(self, arg): self.request_dispatch(arg)
In this case, it is clear that
some_func is yours, whereas
otherFunc is overridden and belong to the superclass. What’s more, the inner calls
request_dispatch are also apparently theirs and yours respectively.
We clearly can’t avoid
mixedCase in the case of overriding methods of a class, or making external calls, but at least this way there is the least amount of ambiguity for both the writer and reader of code.