Comment 4 for bug 98467

Revision history for this message
Jim Fulton (jim-zope) wrote : Re: [Bug 98467] Re: Expose setSite in a sane place

On Sep 14, 2007, at 5:16 PM, Fred Drake wrote:

> Adding a new location for getSite and setSite in a new feature release
> is easy enough, but currently would bump the version number for the
> next
> release from 3.4.0b4 to 3.5.0<something> (probably a1, given that I'd
> like to also add a setSiteFromContext function).
>
> On the whole, this is a really trivial example, but it seems like the
> new API remains distinct from the existing API (esp. since it won't be
> deprecated), and the new function I'm interested in adding would
> not be
> dependent on any changes (beyond the addition itself) to the current
> packages.

I'm having trouble following the paragraph above. Example of what?

> Perhaps this suggests that adding a new, saner API should be done
> using
> a completely separate package rather than bumping the version on an
> existing package.

What's the problem with bumping the version?

> I could see a zc.siteapi package providing getSite,
> setSite, and setSiteFromContext (it's too bad zc.site is taken).

I think having them available at the package level is fine.

> Anyway, I've attached a patch that simply adds getSite and setSite to
> the package module.

In general, I'd prefer that package variables be defined with
zope.deferredinport so as not to create import loops.
I sooooo wish the standard library had something like this.

Jim

--
Jim Fulton mailto:<email address hidden> Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org