Hi there,
On 08/12/2009 12:06 PM, Jim Fulton wrote:
Right. I understood this in the original proposal. Given that it
doesn't break the existing API, I have no major problem with it, which
is why I didn't bother to respond in the first place. I have a small
problem that it fattens an
Thomas Lotze wrote:
Martijn Faassen wrote:
One question to ask is whether getParent and getParents are used all over
the place or just by zope.traversing. If they're only used by
zope.traversing we might not want to move them to a more general place,
but perhaps we can even see about
Martijn Faassen wrote:
One question to ask is whether getParent and getParents are used all over
the place or just by zope.traversing. If they're only used by
zope.traversing we might not want to move them to a more general place,
but perhaps we can even see about removing them.
getParent is
On Wed, Aug 12, 2009 at 3:26 AM, Thomas Lotzetho...@thomas-lotze.de wrote:
...
getParent is used by a number of zope.app.* packages (apidoc, container,
dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its
only other occurrence is in zope.traversing where it is defined, but
On Wed, Aug 12, 2009 at 5:56 AM, Thomas Lotzetho...@thomas-lotze.de wrote:
Jim Fulton j...@zope.com schrieb:
I object to removing API functions that client code might use. (Was
that a trick questions?) What is the point of this exercise?
Sorry, this message shouldn't have been sent in the
Thomas Lotze wrote:
There are two functions in zope.traversing.api, getParent and getParents,
that are rather closely related. The former is implemented right in that
module while the latter adapts its argument to
zope.location.interfaces.ILocationInfo and calls getParents() on that.
Why is
