[Zope-dev] Re: [Zope] ANN: Python Methods 0.1.7 up and over to DC

[Evan Simpson]

"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