[sugar] Python coding conventions

[Dan Williams]

On Thu, 2006-09-28 at 10:20 +0200, Marco Pesenti Gritti wrote: 
> 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?

(obviously activities can do what they want)

Yeah, I'm a tabs guy.  But a lot of the python bindings code for GNOME
that we were using also used tabs, and we felt consistency there too was
worth something.  Maybe not.

People who prefer spaces either (a) like hitting arrow keys a lot, or
(b) have an editor that skips spaces automatically.  Not every editor
does that, or does it consistently.  Presumably Python started using
4-space-width tabs because they couldn't agree on how big a tab was
supposed to be and decided to make the question irrelevant. 

But PEP8 is somewhat ambiguous and only say that you shouldn't mix tabs
& spaces (good god, lets shoot people who do this) and that new code is
"strongly" recommended to use spaces for some unknown reason.  

Another place where we deviate from python core/PEP8: Sugar code will
_ALWAYS_ be UTF-8 encoded.  No questions.  Perhaps we should use PEP263
notation to specify the encoding at the top of every file?  We could
also drop in emacs/vi spacing hints too.

I don't know.  In the end, I wouldn't really fight this, but I don't see
a compelling reason to switch to 4-space spaces "just because".  Stuff
already works with tabs, and as long as you use the same tab widths, it
works just the same as spaces for everyone.

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
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar