Hello, I need replace 0x20 (space caracter ) to Undescore Caracter. I need also a function that UNDO this operation. How can I to do this in DTML sintaxe? Thanks. Marcus Mendes
Hi Marcus, This is untested. Turn "asd asd" into "asd_asd" and output: <dtml-var "_.string.join(_.string.split('asd asd'), '_')"> Turn "asd_asd" into "asd asd" and output: <dtml-var "_.string.join(_.string.split('asd_asd', '_'))"> On Sun, 3 Sep 2000, Marcus Mendes wrote:
Hello,
I need replace 0x20 (space caracter ) to Undescore Caracter. I need also a function that UNDO this operation. How can I to do this in DTML sintaxe?
Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
Hi Chris, Chris McDonough wrote:
Hi Marcus,
This is untested.
Turn "asd asd" into "asd_asd" and output:
<dtml-var "_.string.join(_.string.split('asd asd'), '_')">
Turn "asd_asd" into "asd asd" and output:
<dtml-var "_.string.join(_.string.split('asd_asd', '_'))">
I've seen this on plenty lines of digicools code and wondered about if this is more efficient then using just string.replace() ? I would say string.replace() should be a bit faster. Regards Tino
Tino Wildenhain wrote:
Turn "asd_asd" into "asd asd" and output:
<dtml-var "_.string.join(_.string.split('asd_asd', '_'))">
I've seen this on plenty lines of digicools code and wondered about if this is more efficient then using just string.replace() ? I would say string.replace() should be a bit faster.
I think the reasons may be historical. For a long time the Zope documentation listed the join and split members of the string module, but whoever wrote the documentation the first time around missed out replace. So anyone coming at Zope from the DTML direction is likely not to spot the replace method. Calling _.string.replace requires two attribute lookups and one python method call. replace itself requires zero or one memory allocation for the result. Calling join/split requires four attribute lookups, two python method calls and n+3 memory allocations where n replacements are made (1 allocation when n is 0). So I agree, replace should be faster, although given everything else that is going on, unless you do a lot of them you probably won't notice. -- Duncan Booth duncan@dales.rmplc.co.uk int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3" "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure? http://dales.rmplc.co.uk/Duncan
Hmm.. Shouldn't that be: _.string.join(_.string.split('asd asd'), ' '), '_') Or, alternatively (and more intuitively), _.string.replace('asd asd', ' ', '_') _.string.replace('asd_asd', '_', ' ') - T.J. -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Chris McDonough Sent: Monday, September 04, 2000 5:56 PM To: Marcus Mendes Cc: zope@zope.org Subject: Re: [Zope] Underscore Caracter Hi Marcus, This is untested. Turn "asd asd" into "asd_asd" and output: <dtml-var "_.string.join(_.string.split('asd asd'), '_')"> Turn "asd_asd" into "asd asd" and output: <dtml-var "_.string.join(_.string.split('asd_asd', '_'))"> On Sun, 3 Sep 2000, Marcus Mendes wrote:
Hello,
I need replace 0x20 (space caracter ) to Undescore Caracter. I need also a function that UNDO this operation. How can I to do this in DTML sintaxe?
Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Tue, 5 Sep 2000, T.J. Mannos wrote:
Hmm.. Shouldn't that be:
_.string.join(_.string.split('asd asd'), ' '), '_')
The second argument is implicit on string.split (it defaults to a single space). But your way works too.
Or, alternatively (and more intuitively),
_.string.replace('asd asd', ' ', '_') _.string.replace('asd_asd', '_', ' ')
It should be noted that _.string.replace() is not mentioned in the DTML reference guide. If it exists, it should be used. Sigh. I can't wait for the Zope Book to come out, I'm going to be the first buyer. ;-)
Hi Marcus,
This is untested.
Turn "asd asd" into "asd_asd" and output:
<dtml-var "_.string.join(_.string.split('asd asd'), '_')">
Turn "asd_asd" into "asd asd" and output:
<dtml-var "_.string.join(_.string.split('asd_asd', '_'))">
On Sun, 3 Sep 2000, Marcus Mendes wrote:
Hello,
I need replace 0x20 (space caracter ) to Undescore Caracter. I need also a function that UNDO this operation. How can I to do this in DTML sintaxe?
Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
Yep, it's there, but it's not documented. Basically, anything in the python "string" module should be accessible from Zope DTML. Now, who do I have to beat up to get the 're' module added to the namespace variable??? :) - T.J. -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Chris McDonough Sent: Tuesday, September 05, 2000 7:54 PM To: T.J. Mannos Cc: Marcus Mendes; zope@zope.org Subject: RE: [Zope] Underscore Caracter On Tue, 5 Sep 2000, T.J. Mannos wrote:
Hmm.. Shouldn't that be:
_.string.join(_.string.split('asd asd'), ' '), '_')
The second argument is implicit on string.split (it defaults to a single space). But your way works too.
Or, alternatively (and more intuitively),
_.string.replace('asd asd', ' ', '_') _.string.replace('asd_asd', '_', ' ')
It should be noted that _.string.replace() is not mentioned in the DTML reference guide. If it exists, it should be used. Sigh. I can't wait for the Zope Book to come out, I'm going to be the first buyer. ;-)
Hi Marcus,
This is untested.
Turn "asd asd" into "asd_asd" and output:
<dtml-var "_.string.join(_.string.split('asd asd'), '_')">
Turn "asd_asd" into "asd asd" and output:
<dtml-var "_.string.join(_.string.split('asd_asd', '_'))">
On Sun, 3 Sep 2000, Marcus Mendes wrote:
Hello,
I need replace 0x20 (space caracter ) to Undescore Caracter. I need also a function that UNDO this operation. How can I to do this in DTML sintaxe?
Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Tue, 5 Sep 2000, T.J. Mannos wrote:
Now, who do I have to beat up to get the 're' module added to the namespace variable??? :)
I don't think it matters too much who you beat up... :-) You're probably not going to get it from us. There's the perception at DC that 're' isn't appropriate for through-the-web usage because it's possible to write and use regex that sends the Python interpreter thread it's operating within into a neverending loop. Sorry. Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
Chris McDonough wrote:
There's the perception at DC that 're' isn't appropriate for through-the-web usage because it's possible to write and use regex that sends the Python interpreter thread it's operating within into a neverending loop. Sorry.
Am I the only one who thinks this is silly? One of Zope's key strengths is its granular security, right? So why isn't it the reponsibility of the site designer/maintainer/owner/whatever to ensure that only people he trusts have the ability to write DTML? It seems like that perception is hobbling Python Methods, in particular, by removing useful stuff like the re module because the assumption is being made that people editing TTW code will be untrusted. IMH(umble), either you don't have confidence in Zope's security, or you're assuming your users are stupid (that may be fair for a lot of us, but still ;-) Comments? :-) Chris
Hi, Chris Withers wrote:
Chris McDonough wrote:
There's the perception at DC that 're' isn't appropriate for through-the-web usage because it's possible to write and use regex that sends the Python interpreter thread it's operating within into a neverending loop. Sorry.
Am I the only one who thinks this is silly?
One of Zope's key strengths is its granular security, right? So why isn't it the reponsibility of the site designer/maintainer/owner/whatever to ensure that only people he trusts have the ability to write DTML?
It seems like that perception is hobbling Python Methods, in particular, by removing useful stuff like the re module because the assumption is being made that people editing TTW code will be untrusted.
IMH(umble), either you don't have confidence in Zope's security, or you're assuming your users are stupid (that may be fair for a lot of us, but still ;-)
Comments? :-)
I think the granularity could be finer. If one could give some users access to more 'riscy' modules and some not, it schould be sufficient. I schould write a proposal for thru the web python products... *g* Greetings Tino
i for my part think it makes sense. not just from a security standpoint (think of those sites that allow members who are not necessarily hand-picked to write DTML or attempt to do so) but also from a knowledge level standpoint. who wants their site crashed just because the new programmer doesn't know how to use that re functionality correctly? looking back at all the products and projects i have been involved in i did not have to use the re module a single time. as you know, you can still use the whole module in zope code that resides on the filesystem, like in products or in external methods. i'd rather be inconvenienced once every few months than basically invite denial of service attacks. jens ---------------------------- Jens Vagelpohl The VW Type 4 on the Web: http://www.type4.org ---------------------------- on 9/6/00 5:43, Chris Withers at chrisw@nipltd.com wrote:
Chris McDonough wrote:
There's the perception at DC that 're' isn't appropriate for through-the-web usage because it's possible to write and use regex that sends the Python interpreter thread it's operating within into a neverending loop. Sorry.
Am I the only one who thinks this is silly?
One of Zope's key strengths is its granular security, right? So why isn't it the reponsibility of the site designer/maintainer/owner/whatever to ensure that only people he trusts have the ability to write DTML?
It seems like that perception is hobbling Python Methods, in particular, by removing useful stuff like the re module because the assumption is being made that people editing TTW code will be untrusted.
IMH(umble), either you don't have confidence in Zope's security, or you're assuming your users are stupid (that may be fair for a lot of us, but still ;-)
Comments? :-)
Chris
On Wed, 6 Sep 2000, Chris Withers wrote:
Chris McDonough wrote:
There's the perception at DC that 're' isn't appropriate for through-the-web usage because it's possible to write and use regex that sends the Python interpreter thread it's operating within into a neverending loop. Sorry.
Am I the only one who thinks this is silly?
Probably not.
One of Zope's key strengths is its granular security, right? So why isn't it the reponsibility of the site designer/maintainer/owner/whatever to ensure that only people he trusts have the ability to write DTML?
It is.
It seems like that perception is hobbling Python Methods, in particular, by removing useful stuff like the re module because the assumption is being made that people editing TTW code will be untrusted.
TTW people are implicitly untrusted. This is core to the security model.
IMH(umble), either you don't have confidence in Zope's security, or you're assuming your users are stupid (that may be fair for a lot of us, but still ;-)
I dont think either statement is true. It is because there are restrictions that Zope TTW scripting is "safe." It's designed to be more safe than expressive. Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org
Chris Withers writes:
Chris McDonough wrote:
There's the perception at DC that 're' isn't appropriate for through-the-web usage because it's possible to write and use regex that sends the Python interpreter thread it's operating within into a neverending loop. Sorry.
[snip]
It seems like that perception is hobbling Python Methods, in particular, by removing useful stuff like the re module because the assumption is being made that people editing TTW code will be untrusted.
I think the re module is a good example for arguing that DTML and Python Methods should have different criteria for deciding what modules are available (and separate permissions for users, if they don't already). Somehow, the idea of mixing regexps and DTML gives me chills, but I agree that it is a perfectly reasonable tool to want to use in Python Methods. This relates more the crusade to depricate DTML programming as opposed to DTML report writing than it does to security concerns.
From: Chris Withers <chrisw@nipltd.com>
One of Zope's key strengths is its granular security, right? So why isn't it the reponsibility of the site designer/maintainer/owner/whatever to ensure that only people he trusts have the ability to write DTML?
Fear not. In the brand new shiny PythonMethods Product coming soon (really!) to a Zope near you, you will have the ability to say: ModuleSecurityInfo('re').protect('compile', 'Use the "re" module') ...and suddenly anyone to whom you grant 'Use the "re" module' permission will be able to 'from re import compile' in their Python Methods. Anyone else will be able to 'import re', but not access any of its contents. Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
From: Chris Withers <chrisw@nipltd.com>
One of Zope's key strengths is its granular security, right? So why isn't it the reponsibility of the site designer/maintainer/owner/whatever to ensure that only people he trusts have the ability to write DTML?
Fear not. In the brand new shiny PythonMethods Product coming soon (really!) to a Zope near you, you will have the ability to say:
ModuleSecurityInfo('re').protect('compile', 'Use the "re" module')
...and suddenly anyone to whom you grant 'Use the "re" module' permission will be able to 'from re import compile' in their Python Methods. Anyone else will be able to 'import re', but not access any of its contents.
Now THAT! Rocks! -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password.
Evan Simpson writes:
Fear not. In the brand new shiny PythonMethods Product coming soon (really!) to a Zope near you, you will have the ability to say:
ModuleSecurityInfo('re').protect('compile', 'Use the "re" module')
...and suddenly anyone to whom you grant 'Use the "re" module' permission will be able to 'from re import compile' in their Python Methods. Anyone else will be able to 'import re', but not access any of its contents.
Thank you! I was going to follow Chris McDonough's suggestion and add something to the Wiki about this but your solution is just perfect. Of course I have a couple of questions since I couldn't find any mention of this in the Wiki: Does this work for any module or just a semi-safe subset? How are submodules handled? Just put the full path in the ModuleSecurityInfo call? Can you grant permissions for all children of a parent module (scary!)?
From: Dan L. Pierson <dan@sol.control.com>
Does this work for any module or just a semi-safe subset?
How are submodules handled? Just put the full path in the ModuleSecurityInfo call? Can you grant permissions for all children of a parent module (scary!)?
http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/GuardedImport ...is a good place to start learning about this. Any module can be made available -- it's up to the Zope administrator (or Product author) to decide what they can safely expose, under what terms. Cheers, Evan @ digicool & 4-am
Evan Simpson writes:
From: Dan L. Pierson <dan@sol.control.com>
Does this work for any module or just a semi-safe subset?
How are submodules handled? Just put the full path in the ModuleSecurityInfo call? Can you grant permissions for all children of a parent module (scary!)?
http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/GuardedImport
I looked there. It says something about how import restrictions will be implemented but nothing at all about what the limitations will be or what the syntax for interacting with the restriction mechanism will be. For example, your email is the only reference I can find to ModuleSecurityInfo.
...is a good place to start learning about this. Any module can be made available -- it's up to the Zope administrator (or Product author) to decide what they can safely expose, under what terms.
That seems reasonable.
From: Dan L. Pierson <dan@sol.control.com>
http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/GuardedImport
I looked there.
Ah, but I was sneaky and went and updated it just before posting ;-) You do have to follow a link or two, but it isn't hard to find (any more). Cheers, Evan @ digicool & 4-am
Evan Simpson writes:
Ah, but I was sneaky and went and updated it just before posting ;-) You do have to follow a link or two, but it isn't hard to find (any more).
Thanks a lot! That'll teach me not to refresh the page when I check back :-) It now answers all my questions.
On Tue, 5 Sep 2000 20:23:47 -0600, "T.J. Mannos" <MannosTJ@slcc.edu> wrote:
Now, who do I have to beat up to get the 're' module added to the namespace variable??? :)
Not a good idea.... its too easy for a buggy regex to eat up lots of memory and processor time. Toby Dickenson tdickenson@geminidataloggers.com
participants (11)
-
Bill Anderson -
Chris McDonough -
Chris Withers -
Dan L. Pierson -
Duncan Booth -
Evan Simpson -
Jens Vagelpohl -
Marcus Mendes -
T.J. Mannos -
Tino Wildenhain -
Toby Dickenson