[sugar] Python coding conventions
Thu Sep 28 13:32:19 EDT 2006
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.
> Connecting to some of the other discussion, it seems that the daemon is
> really an application, not a library, and so is handled differently.
More information about the Sugar-devel