[sugar] Re: Python Style Guide

[Johan Dahlin]

>>  >__init__.py files should generally contain no substantive code.
>> Instead they should import from >other modules. Importing from other
>> modules is done so that a package can provide a front-facing >set of
>> objects and functions it exports, without exposing each of the
>> internal modules in the >package. Note however that this causes the
>> submodules to be eagerly imported; if this is likely to >cause
>> unnecessary overhead then the import in __init__.py should be
>> reconsidered.
>>
>> Can you give an example of this? I think it would be useful to have it
>> on the guide too. Is it part of PEP-8 in any way?
> 
> This was my addition.  __init__.py can be a little tricky, because it
> will swallow ImportErrors and maybe some other errors.  (This way if you
> __init__.py is broken, the entire package won't become unusable.)  For
> this reason I prefer not to put too much into those files.  Also I must
> admit an Emacs bias, where I like it when files tend to have more unique
> names than __init__; but I that's not a real justification ;)

As an fellow Emacs user I used to share your opinion about unique filenames
until I found that default emacs configuration is utterly broken.
Add this to your .emacs and you'll be happy:

(setq uniquify-buffer-name-style 'post-forward-angle-brackets)

However I consider unique filename a plus but not a necessity, it's nice to
be able to refer to a file, eg: 'I think the bug is in base.py' without
having to mention the domain/context of the module.

> As for the imports, if you have:
> 
>   mypkg/__init__.py
>   mypkg/main.py
> 
> And in __init__.py you have:
> 
>   from mypkg.main import MyProvider
> 
> Then other people can do:
> 
>   from mypkg import MyProvider
> 

In generally I dislike this kind of aliasing, because it makes it breaks
the assumption that an object a.b.c can be found in a/b/c.py, eg adding
a consistent import style makes it possible to map:

from foo.bar.baz import noogie

to the noogie object in foo/bar/baz.py

Which I consider more important then removing a couple of characters in the
line you import an object.

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.

>> *> Is _() always defined?
>>
>> Nope, I think you need to import it from gettext.
> 
> OK; are we just using plain gettext for everything?  I've been
> encountering places where people use fancier _'s, but I think that's
> because in server-side apps you might be supporting multiple language
> simultaneously, which isn't an issue for OLPC.
> 
> In some of these cases people often put _ in __builtins__.  Which seems
> convenient, except you end up doing this for portability:

Putting it in __builtins__ break source code analyzers such as pyflakes,
pychecker.

Modifying __builtins__ is always a bad idea, as it surprises people
not very familiar with the code.

Johan