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