It's a design decision, enforced by a "papal edict" (Jim hates REQUEST.set).
Sometimes papal bulls are, in the American slang sense, just bull.
I agree. Luckily, Zope is extensible to that point that someone can create their own tags to do this. http://www.zope.org/Members/ivo/SetTag
You know, I understand this, to a point. But it does have a very real cost (particularly in DTML), and I think the cost was overlooked because zope.com is so heavily into zope as document management system, rather than an application server.
Errr.. well, we do lots of jobs. Very few of them are document management systems; mostly we build content management applications. I'm not sure what the difference would be, though. Zope is an appserver and we use it as such to build apps.
If you are using zope heavily as an application server, you have a very typical pattern of receive form, canonify data (always strip, often take to a particular case), validate data, and store or otherwise process the data. There is no reason to have the canonify/validate steps be part of the processing procedure. Both for reasons of reuse, and general clarity, they really belong in separate methods.
But now you have a problem. You have to get the canonified version of the REQUEST data back to the processing method. And I know of (in DTML) no other way than using REQUEST.set.
You can pass arguments to DTML methods & documents from both Python Scripts and other DTML methods/documents (as well as ZPT). (re: http://www.zopelabs.com/cookbook/992031125) It's not pretty, but it does work. I think the awful DTML object call signature is at the root of the issue you talk about, otherwise we'd just say "pass it in as an argument" and this issue would disappear. As you say, ZPT offers namespaces for this kind of thing. We'd like to do the same thing for DTML (see http://dev.zope.org/Wikis/DevSite/Proposals/DTMLplusTALES) but the call semantics are so "baked-in" that it would be terribly difficult (maybe impossible) to do so in a backwards-compatible way.
It feels like zope.com makes a mistake in using the "closing designer to developer loop" as the primary seling point of ZPT.
It is a cleaner system, no doubt about that. - C