Strings as input to the in tag: inconsistent
hi! i've posted this problem on the zope-list a couple of days ago with no reply so i'm trying zope-dev now: i'm using this code to output A B C ... Z: <!--#in "_.string.uppercase"--> <!--#var sequence-item--> <!--#/in--> this works fine in my Zope-1.10.2/Linux installation but Zope-1.10.2/Win95 generates this error message: Error type: InError Error value: Strings are not allowed as input to the in tag. can someone explain this inconsistency? why are strings allowed on linux but not on win95? thilo
At 10:28 26/05/99 , Thilo Mezger wrote:
hi!
i've posted this problem on the zope-list a couple of days ago with no reply so i'm trying zope-dev now:
i'm using this code to output A B C ... Z:
<!--#in "_.string.uppercase"--> <!--#var sequence-item--> <!--#/in-->
this works fine in my Zope-1.10.2/Linux installation but Zope-1.10.2/Win95 generates this error message:
Error type: InError Error value: Strings are not allowed as input to the in tag.
can someone explain this inconsistency? why are strings allowed on linux but not on win95?
Are you sure you are using the same version of python on both platforms? You should get the same error on Linux as well, but it seems that string.uppercase there returns a sequence of a type other than string. On the Linux system, type 'python', then 'import string', and then 'string.uppercase' (all without the quotes). It should print the string 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' (with the quotes). If it does, then somehow type checking is broken on your Linux python. To check this, type: 'type(string.uppercase) is type("")'. It should print 1. If it doesn't, that's where your problem lies. If 0, look at 'type(string.uppercase)'. I do not know what it will say, but whatever it is, it probably will be a bug. Right now there is no easy way to convert _.string.uppercase into a sequence of a type other than string, without resorting to external methods. The next version of Zope will contain a _.range function, which is similar to the default python range function. With that you could do: <!--#in "_.range(_.len(_.string.uppercase))"--> <!--#var "_.string.uppercase[_['sequence-item']]"--> <!--#/in--> -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-6254545 Fax: +31-35-6254555 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
Martijn Pieters wrote:
Are you sure you are using the same version of python on both platforms?
well, python-1.5.1 on linux using the zope-1.10.2 source install and the binary installation on win95 but that also ships with python-1.5.1
You should get the same error on Linux as well, but it seems that string.uppercase there returns a sequence of a type other than string.
but i don't want to get the same error on linux - i want the win95 version to work!!! :-)
1. If it doesn't, that's where your problem lies. If 0, look at 'type(string.uppercase)'. I do not know what it will say, but whatever it is, it probably will be a bug.
nope, everything seems to be OK with my python/linux: the type of string.uppercase is StringType and type(string.uppercase)==type('') returns 1. what i have tried now is this: <!--#in title_or_id--> <!--#var sequence-item--> <!--#/in--> with "title_or_id" being the built-in DTML string property of course. and again: linux does it but win95 fails (as usual you might say - but probably not with zope... :-) i've had a look at DT_In.py and there's this code in the renderwb method (on both platforms of course): if type(sequence) is type(''): raise 'InError', ( 'Strings are not allowed as input to the in tag.') why aren't strings allowed as input? in python, strings are sequence types (see ch. 3.2 in the python reference guide) - so why shouldn't i use them with the #in-tag?! and my zope/linux proves that this is possible... could someone please spread some light on this strange phenomena...?! confused... thilo
Thilo Mezger wrote:
hi!
i've posted this problem on the zope-list a couple of days ago with no reply
I saw a reply. Hm.
so i'm trying zope-dev now:
i'm using this code to output A B C ... Z:
<!--#in "_.string.uppercase"--> <!--#var sequence-item--> <!--#/in-->
this works fine in my Zope-1.10.2/Linux installation but Zope-1.10.2/Win95 generates this error message:
Error type: InError Error value: Strings are not allowed as input to the in tag.
This is exactly the same error I get on Linux. You should always get this error. Maybe you are getting a cached page.
can someone explain this inconsistency?
No. I can't even believe it. ;) I certainly can't repoduce it. The in tag is not willing to iterate over a string and _.string.uppercase is a string.
why are strings allowed on linux but not on win95?
They aren't. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Jim Fulton wrote:
No. I can't even believe it. ;) I certainly can't repoduce it. The in tag is not willing to iterate over a string and _.string.uppercase is a string.
again, i have created a dtml document which looks like this: <!--#var standard_html_header--> <h2><!--#var title_or_id--></h2> <p> <!--#in mystring--> <!--#var sequence-item--> <!--#/in--> </p> <!--#var standard_html_footer--> "mystring" is a string property of this document and the in tag is iterating over this string just like you would expect python to iterate over a string. no problems at all and i find this very convenient. how can i make you believe that this is working on my machine? you can find the document at: http://www.eevolute.com/Zope/Thilo/instring no, i'm not trying to fool you - this "instring" document looks exactly like the DTML code above... :-) cheers thilo ps: somehow i start feeling a little bit strange with so many people complaining about features not working and i'm complaining that something is working that should not work... :-)
At 18:54 30/05/99 , Thilo Mezger wrote:
Jim Fulton wrote:
No. I can't even believe it. ;) I certainly can't repoduce it. The in tag is not willing to iterate over a string and _.string.uppercase is a string.
again, i have created a dtml document which looks like this:
<!--#var standard_html_header--> <h2><!--#var title_or_id--></h2> <p> <!--#in mystring--> <!--#var sequence-item--> <!--#/in--> </p> <!--#var standard_html_footer-->
"mystring" is a string property of this document and the in tag is iterating over this string just like you would expect python to iterate over a string.
Puzzling indeed. Somewhere the test fails.. Could you do some debugger tracing or something? In DT_In.py, around the import lines, add 'import pdb', and in the renderwob method (renderwb without an 'o' is for #in tags in batch mode (i.e. using the size attribute), you should add the line 'pdb.set_trace()' somewhere at the beginning, or at least before the test for string type. Now restart your Zope server. When you now load the DTML Document, you'll notice that your browser will wait for the document. At the prompt where you started Zope, the Python Debugger prompt will be waiting for input. 's' is one step, 'n' is stepping over (do not go into a subroutine), 'r' is return from this method (it will first jump to the point where it is about to return) and 'c' is continue. Now you can step to the test, and because you are in python, do some testing yourself. Let us know the results! When you're done, you might have to hit 'c' several times, because of the fact that ZServer is multi-threaded. Remove the debugging code from DT_In.py, and restart your server. Again, it may be that you have to coax ZServer along with some more returns (repeats last command) or 'c's (when the last command has been blanked because you hit another 'pdb.set_trace()'), before it actually will restart.
no problems at all and i find this very convenient.
I would find it convenient as well, but I think DC had a reason to exclude string sequences. DC? -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-6254545 Fax: +31-35-6254555 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
participants (3)
-
Jim Fulton -
Martijn Pieters -
Thilo Mezger