Gang, I've committed in Evan Simpson's Python Methods into the core distribution, however there are a few changes, some minor, some major: * All pieces of the unsafe version have been removed, this is non-negotiable. * document_src has been protected by a new permission * Line endings have been fixed on a lot of stuff to be UNIX having said that, there are two issues I'd like to discuss: * Object traversal, and traversal_subpath * Access to things like the formatters via "magic namespace" Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Christopher Petrilli wrote:
I've committed in Evan Simpson's Python Methods into the core distribution,
Woohoo!
however there are a few changes, some minor, some major:
* All pieces of the unsafe version have been removed, this is non-negotiable.
Do you mind if I put up an XXXPythonMethod Product for those reckless souls who want them?
* Object traversal, and traversal_subpath
In retrospect, these aren't necessary if people are willing to use SiteAccess. If they prove to be popular, you should probably remove their "magical" quality and put an "Allow traversal?" checkbox on the main edit form.
* Access to things like the formatters via "magic namespace"
There have been several times when I've wanted access to these in *DTML*, much less PMs, as in: <dtml-call expr="REQUEST.set('foo', ??how_do_I_call_a_special_format??(the_text_to_format))"> Yes, I could put a DTML Method in my root folder for each special format, containing nothing but <dtml-var arg the_format>, but that's painfully kludgy. Perhaps dtml-let could be extended to allow something like: <dtml-let foo=the_text_to_format html-quote upper bar="2+2"> <dtml-comment>Blech!</dtml-comment> I'd rather just have them available in the same way that the _.string or _.math stuff is, perhaps through _.string.format.* That reminds me: Do you know why tuple, list, map, reduce, and filter aren't surfaced? Is it the "risk" of turning strings into lists? Cheers, Evan @ 4-am
On 12/17/99 3:41 PM, Evan Simpson at evan@4-am.com wrote:
Christopher Petrilli wrote:
I've committed in Evan Simpson's Python Methods into the core distribution,
Woohoo!
however there are a few changes, some minor, some major:
* All pieces of the unsafe version have been removed, this is non-negotiable.
Do you mind if I put up an XXXPythonMethod Product for those reckless souls who want them?
Nope, of course not. You can even make them sing and dance. I just wanted to make sure that Zope didn't ship with this because of the risks involved with it. This was too frightening to contemplate.
* Object traversal, and traversal_subpath
In retrospect, these aren't necessary if people are willing to use SiteAccess. If they prove to be popular, you should probably remove their "magical" quality and put an "Allow traversal?" checkbox on the main edit form.
This is what popped into my mind, so I'll probably whip this in in the next few days. How it gets done is a separate issue :-)
* Access to things like the formatters via "magic namespace"
There have been several times when I've wanted access to these in *DTML*, much less PMs, as in: <dtml-call expr="REQUEST.set('foo', ??how_do_I_call_a_special_format??(the_text_to_format))">
I agree, so perhaps this is a bigger issue that needs to be "thunked" :-) Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
At 03:52 PM 12/17/99 -0500, Christopher Petrilli wrote:
* Access to things like the formatters via "magic namespace"
There have been several times when I've wanted access to these in
*DTML*, much
less PMs, as in: <dtml-call expr="REQUEST.set('foo', ??how_do_I_call_a_special_format??(the_text_to_format))">
This is perhaps more appropriate for DTML than for PythonMethods, but here is a possible proposal... Make the __call__ method of the "_" object look for a positional parameter. If present, format it using the formats specified by the keyword parameters, and return the result. Thus: <dtml-var expr="_(thingToFormat, html_quote=1, newline_to_br=1)"> Would be equivalent to: <dtml-var thingToFormat html_quote newline_to_br> If PythonMethods were able to either use the standard "_" object (when passed in by a DocumentTemplate), or use "import _" to get a fresh "_" object otherwise, then matters would be covered either way. The main objection I see to this is that it's mingling two totally different uses of _(). Of course, the usual use of _() is not relevant to PythonMethods, but it is in DTML if you prefer not to use "let". The objection could be perhaps be mitigated by deprecating the old use of _() in favor of dtml-let, but then given the recent let/local/set discussion, perhaps that's not a good idea. Sigh. Now that PythonMethods are in the Zope CVS, I may take a whack this weekend at adding another option to them, if other people don't find it offensive (and perhaps even if they do... ;) ). ASP syntax. That is: <% if foo>1: %> The value of foo is <%= foo %>. <% else: %> Foo isn't worth much. <% end if %> I already have a robust ASP->Python translator I've had in production use for years, so incorporating it into PythonMethods should be just a matter of adding a syntax option, and a call to the translator at just the right moment. The translator makes up for the infamous ASP whitespace problem by implementing block end syntax (end if, end for, end while, end def, etc.). Anyway, with this syntax, and the "_" proposal the previous formatting example could be rendered: <%= _(thingToFormat, html_quote=1, newline_to_br=1) %> And, what's more, this: <%= _(id) %> Would give you back either id or id() depending on whether id was callable. Voila, PythonMethods would now be able to do anything that core DTML can, but with a consistent syntax and without hidden conversions. And that includes generating HTML. One of the nifty things about ASP syntax is that a lot of off-the-shelf editing tools support it, or at least don't choke on it. What's also nice about it, is that people who have ASP experience can leverage their understanding to a greater extent than they can with DTML. Python is a lot like what VBScript ought to have been. :)
"Phillip J. Eby" wrote:
Now that PythonMethods are in the Zope CVS, I may take a whack this weekend at adding another option to them, if other people don't find it offensive (and perhaps even if they do... ;) ). ASP syntax. That is:
<% if foo>1: %> The value of foo is <%= foo %>. <% else: %> Foo isn't worth much. <% end if %>
I already have a robust ASP->Python translator I've had in production use for years, so incorporating it into PythonMethods should be just a matter of adding a syntax option, and a call to the translator at just the right moment. The translator makes up for the infamous ASP whitespace problem by implementing block end syntax (end if, end for, end while, end def, etc.).
Sounds more like you might want to subclass PythonMethod to make a new ASP Method class (and perhaps ASP Document?). Depending on what your syntax allows, you might even want to work with DTML instead. Then again, there's always this mysterious new multi-syntax thing DC has been teasing us with ;-) Cheers, Evan @ 4-am
ZPublisher.Publish.publish_module incorrectly calls the exception() method of the *old* response object (i.e., an HTTPResponse) when an exception occurs. This results in an xmlrpclib.ProtocolError on the calling end, rather than a Fault() as should occur. To correct, change the 'except:' clauses of publish_module() to call request.response.exception() instead of just response.exception(). This bug has been submitted to the Collector. There are a couple of other odd behavior patterns relating to XML-RPC calls and ZPublisher/Zope that Ty and I are trying to nail down; hopefully we'll have more precise definitions, if not fixes for them, sometime soon.
participants (3)
-
Christopher Petrilli -
Evan Simpson -
Phillip J. Eby