[Zope3-dev] Packaging conventions (was Re: PyCon DC 2003: Call For Papers)
Jim Fulton
jim@zope.com
Sat, 14 Dec 2002 15:30:29 -0500
Phillip J. Eby wrote:
> At 04:28 PM 12/13/02 -0500, Jim Fulton wrote:
>
>> Phillip J. Eby wrote:
>> ..
>>
>>> from peak.naming import api as naming
>>
>>
>> And this is good ... why?
>
>
> 1. Everything in the naming API is then only one dot away
>
> 2. Access is via a prefix ("naming.") so the top-level namespace in the
> importing module isn't cluttered or conflicting.
You don't need an api module for this. You could just:
from peak import naming
...
>> What is the advantage of api over __init__?
>
>
> Makes it possible for packages which want to reuse part of a package,
> not to require the whole thing to be imported. This can slash the
> startup and runtimes for small scripts enormously (in proportion to the
> script's total run time).
But then these can't import api either, as api would have the same
effect.
I would say that __init__ should only expose things that are really
always wanted. A package could have other modules, useful in some cases
that aren't exposed by init.
> There are also some advantages to simplifying import order for
> interdependent packages; For example, if you have a package A whose
> classes want to provide an interface from package B, but package B
> contains things that depend on A's classes. Being able to say:
>
> A:
> from B.interfaces import ISomething
>
> B:
> from B.somemodule import Something
>
> Without having to sort out a precise ordering in the package __init__
> modules can be a nice convenience.
I'm confused. Neither of the above import api. I also don't
follow the second example.
Jim
--
Jim Fulton mailto:jim@zope.com Python Powered!
CTO (888) 344-4332 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org