[Zope3-dev] Big import blocks

[Guido van Rossum]

> >  > Assuming this data is roughly correct, we can cut the number of this
> >  > particular kind of dead chickens roughly in half by creating a module
> >  > with a short name (e.g. "zapi") that imports the 120 most popular
> > 
> > I think this is a useful analysis, and would love to see something
> > like this done instead of continuing the current import hell.  A
> > script to perform the analysis would be good; additions could be made
> > to the API module when something becomes popular enough.
> 
> An API is an Application Programming Interface.

Well, I'm not wedded to the word "API".

> Shouldn't the names for inclusion in this API be taken from an analysis 
> of what names a typical Application needs?

That's what I tried, substituting Zope 3 itself for a typical Zope 3
application.  There's a lot of code inside Zope 3 that I think is at
least somewhat typical of of Zope 3 applications.  E.g. many of the
browser views are dominated by view code, which I expect will be what
applications will do most (the domain-specific code won't use many
Zope 3 names at all).

> I don't think the Zope 3 application is a typical application.

Fair enough.  I don't have access to a typical Zope 3 application
though -- if you have one, I may be able to give you the script I used
for the analysis so you can see for yourself.  (The script needs some
patching up to be more general.)

> Zope 3 is made up of many layers. There are lots of cross-references 
> between these layers that are not so pertinent to other applications.

Agreed.

> (The plumbing of a building serves the insides of the building. Some 
> buildings have the plumbing on the outside, but that's not an invitation 
> to hook up to it from the street.)

Maybe we can make a second, Zope-3 *internal* package that contains
more shortcuts of the proposed kind.

> I'm concerned that an API modeled on what the Zope application needs 
> from the Zope application will be skewed from what other applications 
> will need.

Agreed.

> So, I suggest choosing the names for the API module very carefully,
> with a rationale for why a particular name is chosen over and above
> "it is common in the Zope 3 application".

Sure.

> The zope/app/api.py module should also have an IZopeAppApi interface 
> defined for it (to live in zope/app/interfaces/something).

I am not convinced of the advantage of moving the docs for a module to
a separate interface; I'd rather keep things together.  Anyway, this
module would just gather things that really live elsewhere, and they
are (supposedly :-) already documented there, so the docs for this
module should mainly consist of pointers.

--Guido van Rossum (home page: http://www.python.org/~guido/)