[sugar] Python Style Guide
Tue Nov 14 11:33:49 EST 2006
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
> > 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?
More information about the Sugar-devel