[sugar] Re: Python Style Guide

[Ian Bicking]

Johan Dahlin wrote:
> Oops, I forgot to mention that you also need this module loaded:
> 
> (require 'uniquify)
> 
> Checked using GNU Emacs 21.4 and 22.0.50.

Cool, that does it.  Much nicer.

>>> After all, you're only going to write the code once, but lots of
>>> people are
>>> going to read and try to understand the code.
> 
>> And of course if it means not breaking backward compatibility you
>> definitely should use this style -- e.g., if you moved from a module to
>> a package, and factored your objects into different modules.
> 
> You can also use placeholder modules to provide backwards compatibility,
> That's one of the few cases where I'd actually put code in __init__.py
> files. It needs a little (tiny) bit of infrastructure to be done on demand,
> but that's also desirable even if you use aliasing, you don't want
> all sub-modules to be imported when you import a package, especially in
> the large packages (10-15 modules or so)

There's an empty section on deprecation in the style guide; I was 
planning on putting some notes there about aliasing when deprecating.

>> My vague impression is that _ needs a better implementation than
>> gettext's, with more consideration of threadlocal languages,
>> registration of providers, and whatever else people are adding into
>> their _ implementations.  But without much experience in the subject
>> it's only something I'm detecting by smell ;)
> 
> Don't forget unicode handling; gettext doesn't quite work properly with
> unicode, it always returns a string, regardless of the type of the input.
> It might not matter in all applications, but in ours which happened to
> use SQLObject and UnicodeCol it did.

Wow, gettext is lame.  I notice that at least lgettext is better.  But 
still not good, since it returns an encoded string, just a more 
consistent encoding (and since we're using UTF8 everywhere it hardly 
matters).  It looks like the GNUTranslations class has a ugettext 
method, but there is no gettext.ugettext.

I want to avoid non-unicode text strings as much as possible, which 
means using ugettext.  But I'm not sure what that implies, especially 
lacking a gettext.ugettext function.  I almost feel like each activity 
should do something like:

   from myactivity import _

to make it easier to change strategies if necessary.  Or "from 
sugar.gettext import _" or something like that.  For libraries that need 
to be sugar-agnostic (i.e., weren't developed for sugar specifically) 
it's unclear how this should be coded.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org