Naming and Casing Convention in PyObjC

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 substract, remove_child_node, or perform_caching. In addition, private instance variables and methods are often preceeded by an underscore, creating variables and methods that look like
_words or _add_child_node.

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 perform_caching becomes -(void)performCaching;, which becomes performCaching(self).

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.