Chris Withers wrote:
(Btw, just thought of another one possible name clash: 'response')

no-one uses that is Zope 2 land 'cos of RESPONSE...

Well. Could be that someone uses 'response' as a form variable, as in "the response to a question" in a QandA system, perhaps.

The sad thing about this is that we can only do so much investigation of existing code. The rest is speculation. But it's better to be safe than sorry...

I've thought about introducing the adaption approach now. I think we'd be opening a can of worms since the request objects are likely to be passed from old style code to new style code and vice versa.

I think it's worth at least trying...

Agreed. This thing has always been on my agenda, but it needs thought and time to do it.

I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 doesn't mean that everything from the 'zope' namespace has to work. Five has never made that promise.

Indeed, but in this circumstance, they probably should ;-)


That said, *if* we choose to go with such a configuration option, I think it woudl probably be a good idea to have it disabled by default in the first release and enabled in subsequent releases. That way applications could opt in for the new behaviour earlier than necessary (much like Python's __future__ imports).

OK, I'll buy that, annoying though it'll be for everyone (no-one has spoken up to say "you're gonna break all my code is you use debug, or locale, or response" ;-) )

True. Hey, don't get me wrong. I'm all *for* going forward and make Zope 2's request more like IBrowserRequest. But in the end when I break other people's apps, everyone will be all over me. I'm sure if it was one of your apps, you'd be the first one to complain and declare Zope's rate of change too fast and harmful. ;)

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to