[Zope3-dev] zope.proxy, zope.security dependencies in zope.publisher

Phillip J. Eby pje@telecommunity.com
Thu, 03 Apr 2003 17:00:51 -0500


While evaluating the current state of zope.publisher today, I noticed that 
it has dependencies to zope.proxy.introspection, and from there to 
zope.security.proxy and zope.proxy.context.  These dependencies are as far 
as I can tell, unnecessary for users who are not making use of context 
wrappers or the zope.security package.

It seems to me that the extended dependencies could be removed by simply 
requiring  that 'mapply()' and 'response.setBody()' be called with 
unwrapped objects.  The default 'zope.app' Publication object could 
trivially support both of these requirements in its 'callObject()' method 
(by returning an unwrapped result).  It would then no longer be necessary 
to burden 'zope.publisher' with an understanding of 
proxies.  Alternatively, if the publication interface is used in places 
where it isn't a good idea to return unwrapped objects, having an 
IPublication.removeProxies() method would do the trick.

While zope.publisher also has dependencies to several other zope.* packages 
(zope.component, zope.interface, zope.exceptions, and zope.i8n), it would 
be nice to get rid of the ones like zope.proxy and zope.security that 
aren't absolutely essential to the mission of 'zope.publisher'.  For 
example, couldn't the '_decode()' method of 
'zope.publisher.browser.BrowserRequest' delegate the operation of obtaining 
preferred character sets to the publication object as well?  I'd really 
like to see 'zope.publisher' dependencies constrained to 'zope.interface', 
'zope.exceptions', and 'zope.i18n' -- and I'm not feeling all that positive 
about exceptions and I18N!

Since I'm the one with the itch, I'm willing to do the work to scratch it, 
but I'm not clear on the development process I need to follow.  Who do I 
need to clear these kinds of changes with?  Do I need to make some formal 
proposals?  etc.  Is there any reason why invoking mapply on an unwrapped 
object would be a bad idea, and if so, could we simply change mapply's 
signature to allow passing in a proxy remover?