ANN: Python Methods 0.1.7 up and over to DC
I just uploaded version 0.1.7 of the PythonMethod Product. Here's the CHANGES.txt since 0.1.6: * Nested functions and lambdas are now supported, with full safety. * You can access all of the dtml-var format functions through a builtin dictionary called special_formats (eg: special_formats['html-quote']). * Handing off to Digital Creations for inclusion in CVS. * Packaged with packProduct script, which excludes parent directories and .pyc files. Makes for a smaller package, and doesn't step on ownership/permissions of lib/python/Products path elements. * Added COPYRIGHT.txt, making Wide Open Source licence (BSD-style) explicit. (Mike Goldman provided the text, I provided the silly name). * Jeff Rush donated a PrincipiaSearchSource method, so that PythonMethod objects can be zcataloged to the same degree as DTML Methods. * Also from Jeff Rush, a document_src method, so that the source of PythonMethods can be viewed via a "View Source" link if desired. * If a PM has a 'traverse_subpath' parameter, you can now directly traverse it. The elements of the subpath will then be put into a list in 'traverse_subpath'. (thanks to Anthony Baxter) Cheers, Evan @ 4-am
Did Ty or I ever send you the "isDocTemp=0" fix? If not, here's the deal... if you call a PythonMethod in a context that acquires from a DTML Document (or a ZWikiPage, which is how we found it), the DTML rendering logic thinks that the PythonMethod is a DocumentTemplate (because it's acquiring isDoctemp=1). Setting "isDocTemp=0" in the PythonMethod class fixes this. At 01:17 PM 12/13/99 -0600, Evan Simpson wrote:
I just uploaded version 0.1.7 of the PythonMethod Product. Here's the CHANGES.txt since 0.1.6:
[changes snipped] 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? (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.
"Phillip J. Eby" wrote: [snip]
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.
I'm seconding this loudly! Me too! Regards, Martijn
participants (3)
-
Evan Simpson -
Martijn Faassen -
Phillip J. Eby