After looking at the whole copy thing for some more time, I thought
that it even makes sense to extract the object cloning functionality
to some "zope.copy" (or even "zope.persistentcopy") package that will
contain clone and copy functions as well as ICopyHook mechanism, but
won't contain IObjectCopier implementation, because the "clone" and
"copy" functions from zc.copy are useful without any container
context. Then zope.copypastemove and zope.location could just depend
on the zope.copy, so we won't introduce many dependencies for
zope.location and make people able to easily copy persistent objects
w/o installing on zope.copypastemove or even zope.location.

2009/2/8 Dan Korostelev <>:
> The README.txt of zc.copy says that the components, provided by this
> package is apropriate for inclusion in Zope itself.
> The package provides a more pluggable mechanism for copying generic
> persistent objects (not only ILocation's) as well as a way to register
> post-copy hooks to be executed, which is very useful, for example when
> dealing with persistent objects that have non-ZODB bits (like
> filesystem based files related and so on). However, the package is
> really small and mostly contains modified copies of
> zope.copypastemove's ObjectCopier and zope.location's locationCopy.
> So, I propose to merge the zc.copy package's changes with original
> zope.copypastemove/zope.location and deprecate it. If noone objects,
> I'll do that myself.
> --
> WBR, Dan Korostelev

WBR, Dan Korostelev
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to