In my tutorial for PyObjC and Cocoa one of the key ideas was: PyObjC is Python. PyObjC is Objective-C, too. At no point is that more confusing than when you begin to consider naming your methods and variables. Python's prefered method for writing method names, as discussed in PEP 8, is with all lower cases characters and underscores to separate words.
Thus appropriate function names look like
perform_caching. In addition, private instance variables and methods are often preceeded by an underscore, creating variables and methods that look like
Unfortunately, these naming conventions can quite easily come into conflict with PyObjC's convention for describing Objective-C methods, which overrides of the underscore to be equivalent to a colon in an Objective-C method.
For example, the Python method
remove_child_node(self,node) would appear to be the Objective-C method
remove:child:node:, but only has one argument instead of three. Thus the
remove_child_node method is inaccessible from Objective-C classes, Cocoa bindings, and interface builder.
Even nonsensical placements of underscores, for example the private instance variable
_nodes which don't translate coherently into an Objective C method, will be inaccessible.
Because the standard Python convention doesn't fit, it seems that writing Python functions for PyObjC should have a different convention: write the method as if we were writing Objective-C, and then convert the method definition into Python.
Using this convention, let's rework
remove_child_node(self,node). First we translate it into
-(id)removeChildNode: (id)node;, and then translate that into Python
removeChildNode_(self,node). For a second example, the method
-(void)performCaching;, which becomes
As PEP 8 mentions, there are times when conventions must be overridden for sanity's sake, and this seems like it is one of those times. Using lower-first camel-casing makes PyObjC development a bit more sane in an sparsely documented world, and it seems to me that sanity wouldn't accept anything less.