[sugar] Python coding conventions

[Marco Pesenti Gritti]

Ian Bicking wrote:
> 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.
>

I don't feel strongly one way or another. Spaces have probably the 
advantage to look the same on all editors, which is nice (try to open 
our current code with a stock vim).

When we decided for tabs I remember Dan had a discussion with David 
about this and he was feeling strongly for tabs. Dan?

> * 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.

Eeeeh here comes my hate for python imports. What I'd really want in the 
code is:

from sugar import presence

ps = presence.PresenceService()

Now, is there a way to get that without stuffing all the presence 
service in presence.py. Or more in general can you elaborate on a way to 
organize code in python that doesn't suck :) I guess we have been trying 
to emulate java like packaging with generally one class per file, but 
that doesn't seem to play well with python imports.

Anyway it would be great to solve this in a good way. I hate what we 
have currently.

> 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.
>

Yeah. That was actually just a misunderstanding of the convention (I've 
been using _ for protected and __ for private). I'm replacing __ in the 
code gradually, but it would make sense to go ahead and s/__/_ (well 
expect the cases where __ is actually wanted).

> 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 ?
>

source/sugar/services/presence is the dbus service. It's supposed to be 
private API and it's installed in the datadir rather than in 
site-packages. source/sugar/sugar/presence is the public API, installed 
in site-packages.

Marco