[Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Dieter Maurer wrote:
> Philipp von Weitershausen wrote at 2006-9-5 16:28 +0200:
>> Maciej Wisniowski wrote:
>>>  > I consider this a feature request but not as a bug.
>>> Ehm... I'm not sure whether we understand each other.
>>>
>>> I mean the bug
>> There is no bug.
> 
> Seems a funny interpretation of "no bug" for me...

It's an unfortunate situation. That's what it is.

>>> is that DateDisplayWidget in Zope2.9.4 uses
>>> request.locale which as you said is from Zope3 world. So, as far as I
>>> understand, reference to 'request.locale' shouldn't appear in Zope
>>> 2.9.4 code at all but it does... Do you mean it is correct??
>> DateDisplayWidget expects an IBrowserRequest. Zope 2's request only 
>> pretends to be an IBrowserRequest.
> 
> If that is not a bug (pretending to implement "IBrowserRequest" but not
> doing so) what is a bug?

I'll call this an "issue" for now, but I won't argue semantics here. All 
I can say is that the Five project's promises were never that everything 
from Zope 3 works instantly. And it has also been Five's policy to make 
a quick lie here and there just to get things going. Five usually gives 
you 95% of a certain technology you know from Zope 3. The remaining 5% 
are friction loss due to Zope 2isms like Acquisition, etc.

In order to "sell" Zope 2's request to the Zope 3 machinery, Five 
originally made Zope 2's request an IBrowserRequest -- even though that 
was a lie. When Five was integrated into Zope 2, that lie was carried on 
in Zope 2. I was neither the one to make that initial "lie" nor was I 
there when Five was integrated.

>> At the current state, it can't 
>> implement the whole interface.
> 
> Which means, that there is a bug but you have currently little chance
> to fix it...

The problem with going forward with this and fixing it is the following 
(quoting myself from an earlier email on this thread):

   We can't even just make the Zope 2 request have that attribute
   because of potential backward incompatibilities. Why? Because you
   can do request.locale in Zope 2 right now which is an equivalent
   spelling of request['locale'] (it looks up request variables). If
   existing applications use the attribute access instead of the item
   access (which should clearly be the preferred way, but there's lots
   of Zope 2 legacy), they would break because request.locale would now
   find something else.

   It's not a bug. It's Zope 2's obscenity with __getattr__ APIs
   instead of __getitem__ APIs that's preventing the harmonizing of the
   two implementations, that's all. Both the ObjectManager and the
   request are very good examples of how Zope 2 got this wrong, but
   Zope 3 got it right.

> By the way, you could introduce a configuration option
> that allows the user to determine whether he is more interested
> in a true "IBrowserRequest" request or a more backward compatible
> request.

I'm not sure that that will work. In complicated systems like Plone, you 
might end up with some products that rely on the old way of doing things 
while Plone uses Zope 3 components that obviously want the "true" 
IBrowserRequest request at same time.

Note that I'm well aware of this issue and have thought hard about it. I 
think the only long term solution out of this mess is to get rid of the 
__getattr__ spelling once and for all.

>> That's a known issue, but we can't do anything about it, at least not in 
>> DateDisplayWidget (and numerous other places where request.locale is 
>> used). The problem's roots go deeper.
> 
> That you know it and do not want to change it does not mean that
> "bug" is not an appropriate term...

You're claiming that I don't *want* to change it. That's not true. I am 
thinking hard about this, but I see no easy solution. Of course, I'd be 
more than happy if an easy solution can be found.

Philipp