[Zope3-dev] cleanup of zope/component/__init__.py needed

[Albertas Agejevas]

On Mon, May 31, 2004 at 10:49:43AM -0500, Garrett Smith wrote:
> I'm frustrated with the way the component API has been changed without a
> posting to this list explaining the changes. Looking into the source
> (zope/component/__init__.py), I see various deprecation warnings, some
> commented out, others at the wrong indent level, not getting called
> appropriately.

I am responsible for this change.  I took over the work started by
Steve Alexander and finished it to the point of being commitable.  All
the unit tests and functional tests pass, most Zope 3 code is
converted to the new API, but some of it (especially tests) still
relies on the deprecated backwards compatibility.

I did my best trying to get the deprecation warnings at the right
levels, though.

Some of the deprecation warnings are commented out because they are
triggered by the Zope 3 test suite itself.  This is due to the fact
that lots of tests pass arbitrary objects as the context of component
lookup, and that is deprecated now.

Fixing those tests is a time-consuming work. It involves going through
all the tests that trigger warnings and fixing them by either removing
the context argument from the calls to the CA API or making the
context be acceptable for the new API.

I don't have the time to do the cleanup myself right now, as this
fixed component lookup work already took more than a week of my time,
but I would gladly work on that during the sprints at EuroPython.

> I know we assume corporate responsibility for the code, and I'm happy to
> help out, but I think the owner of these changes should clean this code
> up. This code is too central to be left in this state at this time.
>
> Btw, my preference is to *not* deprecate something like this, given the
> push to stabilize the core framework. Utility lookup is something I want
> to get right, and it's a trivial reordering of arguments.

Well, it is not a trivial reordering of the arguments.  The context
argument should be gone in most of the client code.

Now, by default components are looked up from the nearest site, which
is set as a thread global during traversal.  The context should
be passed only in special circumstances, when the services need to be
looked up in some other context for some reason.  The requirements for
the context argument were made much stricter -- it has to be either
None or adaptable to IServiceService.  There is an adapter which tries
to adapt ILocation to IServiceService by traversing __parent__s.

By the way, Jim does not like the status quo CA API and would rather
have something like::

    IComponentArchitectureAPI(context).getUtility(name)

instead of the current::

    getUtility(name, context=context)

So, even more dire changes are possible in the future.

> I would just humbly request a note posted to this list :-)

I hope this post satisfied your request at least partially.

By the way, the original proposal is available at

http://dev.zope.org/Zope3/FixedDefaultComponentLookup

I apologise for not having written any note on this earlier.  I
thought you have figured everything out when you first wrote a rant
about that.  Also, I was just a humble implementor of the plots done
by Jim and Steve.

Cheers,
Albertas