[sugar] Re: Python Style Guide
Fri Nov 17 14:44:36 EST 2006
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
More information about the Sugar-devel