"Phillip J. Eby" wrote:

Did Ty or I ever send you the "isDocTemp=0" fix?

No, I don't think so. What problems does the mistaken DocTemp-ness cause?

Setting "isDocTemp=0" in the PythonMethod class fixes this.

Send me CVS access instructions and I'll be happy to make the change ;-)

At the risk of excessively critiquing such a young and exciting product, may I suggest that some care be taken w/respect to namespace issues in PythonMethods? That is, rather than adding things like "special_formats" and using special names like "traverse_subpath", couldn't we use import with a special module path?

I was a bit uncomfortable with both of these. In the case of "traverse_subpath", it wasn't clear to me how to decide whether to allow (and capture) direct traversal otherwise. I couldn't use property settings, since PMs don't have those, and I was reluctant to simply leave traversal always turned on. "special_formats" is sheer laziness on my part, since the dict was sitting there, ripe to be popped into the namespace, and with invalid identifiers for keys.

(E.g. "from _Zope.special_formats import html_quote".) Then, specials would not be a part of the common namespace.

To be honest, I'd rather see "from _ import var1,var2,var3" used to get acquired variables, or even "self.var1", etc., rather than just importing everything automatically. The closer that PythonMethods can stay to being "pure" Python, the better off the Zope will be from a teaching standpoint. Avoiding DTML's promiscuous namespace habits would be a step in the right direction.

Definitely. One of the reasons that 'import' is still missing from PMs is that you *can* use attribute and subscript access on a passed-in self or _-namespace to get at the object hierarchy. Since acquisition/REQUEST search aren't performed on bare names like in DTML, I don't feel too bad about bloating __builtins__ a bit. Cheers, Evan @ 4-am