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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
