[sugar] Python Style Guide

[Dan Williams]

On Tue, 2006-11-14 at 10:19 -0600, Ian Bicking wrote:
> Dan Williams wrote:
> >>  > [note: I don't think double underscore should ever be used; maybe 
> >> this should be removed]
> >>
> >> I think it should, it's just confusing.
> > 
> > I am a bit concerned about visibility though; for stuff that should
> > _never_ be used from programs outside of the sugar bindings we should
> > really be using __ to keep the symbols private.  There _are_ things that
> > we need to do that we really don't want to be part of the public API,
> > and that we want to enforce; especially where the implementation details
> > might change quite rapidly over the next few months.  But in general, __
> > should go away.
> 
> Note that __ isn't just private outside of sugar, but private to every 
> function outside of the original class, including functions defined or 
> overridden in subclasses.
> 
> >>  >For simple public data attributes, it is best to expose just the 
> >> attribute name, without complicated >accessor/mutator methods
> >>
> >> I'm not sure I like this... It's quite unusual for non python coders. If 
> >> we want to keep it we should probably elaborate more on it in the guide.
> > 
> > Again, if we expect any of this stuff to change we should be hiding them
> > behind accessors...  I know there are a _ton_ of tricks you can use in
> > Python to maintain backward compatibility, and I've seen & used a few of
> > them before in my python projects.  This is a balance between work we'd
> > have to do in the future to maintain backwards compat and a small amount
> > of adding accessors here and there.
> > 
> > I'm very uncomfortable with exposing stuff like:
> > 
> > class Foo:
> > 	def __init__(self):
> > 		self.var = 1
> > 
> > a = Foo()
> > a.var = 2
> > 
> > because then you can't do any validation and you never know when the
> > variable changes; accessors fix this because you always know when the
> > value changes and you can validate the change and throw exceptions.  If
> > this isn't what you're talking about, ignore me.
> 
> I'm not arguing against single-underscore private variables (like 
> self._var).  Double underscore (e.g., self.__var) is the stuff that does 
> name mangling, which does weird things to introspection tools and 
> subclassing.
> 
> > For example; dbus always returns strings as unicode because the native
> > bus encoding is UTF-8, and you can't just do 'if a == b' where a is
> > unicode and b is encoded.  Therefore, for stuff like that, you always
> > need to use an accessor to either enforce the restriction or to do the
> > conversion yourself.
> 
> Not directly your point, but I do think we need to be very careful about 
> avoiding encoding strings, doing the decoding at the boundaries whenever 
> possible (where dbus is a boundary).

I'd advocate mandating UTF-8 everwhere, but that's just me...  Is there
a way to make python's constant strings (ie, 'a = "something"') always
be Unicode objects?

dan