[sugar] Python coding conventions

[Dan Williams]

On Thu, 2006-09-28 at 11:12 -0500, Ian Bicking wrote:
> Dan Williams wrote:
> > On Thu, 2006-09-28 at 10:20 +0200, Marco Pesenti Gritti wrote:
> >> Ian Bicking wrote:
> > <snip>
> >>> 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.
> > 
> > Slight correction here:
> > 
> > sugar/services/presence is the D-Bus service, which could be written in
> > C, C++, Mono, haskel, python, etc.  It provides a _public_ D-Bus API,
> > and should not go in a python-specific directory because stuff other
> > than python uses it.  If you write a C activity, you'll use it, just
> > like you would use the Shell (which should also not go in
> > python-specific directories).  None of this could can or should be used
> > directly by a python program, as the only _public_ interface for it is
> > the D-Bus API.
> 
> Is this the same as saying that sugar/services/presence is the presence 
> daemon, and sugar/sugar/services/presence is the client code to access 
> that daemon?

That's a good point; however somebody creating sugar apps in Python
should never have to see, nor care, about sugar/services/presence stuff.

> If so, can these be named more distinctly?  I think the potential for 
> confusion is obvious ;)  Maybe presencemanager or presencehub or 
> something like that.  Or not use sugar/sugar/services, but use some 
> other name for the client APIs.

The client APIs are intended to be a thin wrapper around the D-Bus API.
If you look at it from a D-Bus perspective, which you should, the
nomenclature being used makes sense.  Perhaps we want to wrap the D-Bus
API in a more pythony way.

Dan

> Connecting to some of the other discussion, it seems that the daemon is 
> really an application, not a library, and so is handled differently.