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
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 - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -