This is mainly related to Pyblish FTrack which currently uses a mix of snake_case and 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.
1. Module-to-module
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 snake_case?
And perhaps more importantly, with this approach you loose any form of convention across multiple modules, within or between packages.
module1.py
import nonPEP8
def myFunc(arg1, arg2):
return nonPEP8.someFunc(arg1, arg2)
module2.py
def my_other_func(arg1, arg2):
return True
2. Limited
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 dispatchRequest and 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.
Thoughts?