[sugar] Python coding conventions

[Ian Bicking]

Looking at the code some there's really only two things that are not the 
norm in Python coding these days:

* Tabs for indentation.  I know some people feel really strongly that 
tabs are right.  Personally I feel the opposite.  It was a topic of much 
discussion at one time, but now spaces are the norm in all Python code. 
  I don't think consistency with non-Python code is important here, it's 
not like you can copy and paste between languages.

* Module names.  Specifically something like 
sugar.presence.PresenceService -- the convention is now all lower case 
for modules, with no underscores.  The reason for this is that it makes 
modules distinct from both functions and classes.

In this case when you see "PresenceService" in some code you don't know 
if it is a class or a module.  You have to scan back up to the import 
statement to figure that out.  And some places in the code it will be 
spelled PresenceService.PresenceService (which always looks ugly), 
others just PresenceService.


Otherwise there's distutils -- discussed separately.

Well, another pet peeve of mine is __ (double underscore).  Double 
underscore means class private -- as in subclasses won't have access to 
it, not just external code.  Unless they learn the not-very-secret trick 
about how the name mangling works.  Oh, and if the subclass has the same 
name as the superclass (not unlikely) then it won't be private.  I find 
the whole thing really silly, and I think single underscore is Private 
Enough For Anyone.

I guess the only other issue might be with the file layout, a little 
related to distutils.  For instance, why is there 
source/sugar/services/presence and source/sugar/sugar/presence ?

On the subject of capitalization, in my own setups I'll often capitalize 
the "distribution", i.e., the directory that contains the files that 
make up the package (but not the package itself).  So 
source/Sugar/sugar, since source/Sugar isn't a Python package (and due 
to capitalization looks less like one).  And often any other directory 
that might look like a Python package but isn't, I'll try to name in a 
way that makes it obvious (e.g., by putting a "-" in the directory name 
it clearly can't be a package).

Anyway, I think that's it for all the layout issues that have come to 
mind.  Now I have to go and digest the actual code ;)

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org