[Zope-dev] more Zope2.6 fun: ZEO client death.
So I see ZEO clients here falling over all over the place under current 2.6 with: 2003-07-30T07:01:04 ERROR(200) ZEO uncaptured python exception, closing channel ZEO.zrpc.asyncRPC connected '' at 0xc57198 (exceptions.AttributeError:keys [/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|poll|94] [/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|handle_read_event|395] [/export/01/zope/dev_ekit/lib/python/ZEO/smac.py|handle_read|172] [/export/01/zope/dev_ekit/lib/python/ZEO/zrpc.py|message_input|282] [/export/01/zope/dev_ekit/lib/python/ZEO/ClientStorage.py|out_of_band_hook|191] [/export/01/zope/dev_ekit/lib/python/ZEO/Invalidator.py|end|126] [/export/01/zope/dev_ekit/lib/python/ZODB/DB.py|invalidate|318]) The relevant code in current 2.6 CVS: if connection is not None: version=connection._version # Update modified in version cache # XXX must make this work with list or dict to backport to 2.6 for oid in oids.keys(): h=hash(oid)%131 o=self._miv_cache.get(h, None) if o is not None and o[0]==oid: del self._miv_cache[h] (or http://cvs.zope.org/Zope/lib/python/ZODB/DB.py?annotate=1.43.6.4#316 ) The comment is correct. It _does_ need to work with a list or dict. It doesn't right now. If I'm _really_ _really_ lucky, I can have a ZEO client stay up for nearly half an hour before it hits this problem and falls over. The code was committed 2 months ago, as rev 1.43.6.3 Backport atomic invalidations code. This, to me, seems a showstopper for 2.6.2. Anthony ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more Zope2.6 fun: ZEO client death.
Anthony Baxter wrote
So I see ZEO clients here falling over all over the place under current
2.6 with:
2003-07-30T07:01:04 ERROR(200) ZEO uncaptured python exception,
closing channel ZEO.zrpc.asyncRPC connected '' at 0xc57198
(exceptions.AttributeError:keys
[/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|poll|94]
[/export/01/zope/dev_ekit/ZServer/medusa/asyncore.py|handle_read_event|395]
[/export/01/zope/dev_ekit/lib/python/ZEO/smac.py|handle_read|172]
[/export/01/zope/dev_ekit/lib/python/ZEO/zrpc.py|message_input|282]
[/export/01/zope/dev_ekit/lib/python/ZEO/ClientStorage.py|out_of_band_hook|191]
[/export/01/zope/dev_ekit/lib/python/ZEO/Invalidator.py|end|126]
[/export/01/zope/dev_ekit/lib/python/ZODB/DB.py|invalidate|318])
For what it's worth, the following patch makes it work for me.
RCS file: /export/00/cvsroot/Zope/lib/python/ZODB/DB.py,v
retrieving revision 1.1.1.11
diff -u -r1.1.1.11 DB.py
--- DB.py 2003/07/24 08:35:40 1.1.1.11
+++ DB.py 2003/07/30 08:57:02
@@ -315,6 +315,8 @@
version=connection._version
# Update modified in version cache
# XXX must make this work with list or dict to backport to 2.6
+if type(oids) is type(''):
+oids = { oids: 1 }
for oid in oids.keys():
h=hash(oid)%131
o=self._miv_cache.get(h, None)
Note that despite the comment, it's in fact getting passed a single
oid as a string, not a dict or a list. I have no idea if there's _also_
code that might be passing a list, which will still be broken.
I'm not committing this to the CVS yet, because I'm not 100% positive
it's the correct fix. It certainly _seems_ to be, and I've now got
ZEO clients that actually work worth a damn...
Anthony
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
hmm, well to be clear, you're still using implicit acquisition if you say span tal:content=here/foo ... /span However, TAL is much better about using explicit namespaces Yes, explicitly using implicit acquisition. I'll give you that. If Zope is your first exposure to Python, I'm not sure if you can appreciate what I mean. :-) Possibly not. I've often been thown into the deep end of projects. reference manual? which one? The Zope Book? (a fair amount of python is in it these days.) ZOpe Developers' Guide? (lots of python there.) I was referring to Guido's Python Reference Manual, which is less a reference of python modules, rather a reference of how python itself was written. No offence intended. There's lots of python in both Zope books, and I refer to them regularly. - Write as much as possible of your product's features in a class that doesn't inherit from *any* zope-specific base classes. I can take that advice. Seems reasonable enough, and makes the python more reusable in any case. I'm currently trying to write the interface to integrate a wholesaler XML response into our database and finding myself falling between XML stools. My notion was to convert it to a local XML format before importing that to the database. I figured that this layer would insulate against change in a similar manner to the above, but it seems that generating xslt programmatically is not something that people are doing much yet. Thanks for your time. Christopher. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
Paul Winkler wrote: On Tue, Jul 29, 2003 at 04:43:21PM -0400, Shane Hathaway wrote: a tal:attributes=href here/format:url_quote / Where do you put the argument? I don't see some_url. Oops, I meant this: a tal:attributes=href some_url/format:url_quote / To me, that's a vast improvment, and it's only one example. It also raises some new questions that are about on par with what would be needed to understand the zope 2 version: What kind of thingie is format:? Where can I find it if I want to learn what else it can do? What do I do if I want format:some_custom_format? How could I replace or augment the format thingie and not break any template that uses it? It is intended that format: refers to a Python module. You should not extend that module, unless you're developing Zope itself. You'd find documentation on it in the Zope Book. If you need more functionality, you can configure your own prefixes. You know what was actually wrong with DTML? The lack of Python Scripts. Without Python Scripts, everyone used DTML as a programming language. Once Python Scripts came around, DTML became a reasonable templating language again. If DTML used TALES expressions, it would be just as clean as ZPT. I think I just said this in another post :) Maybe you didn't draw the same conclusion, then. ;-) My conclusion: since the main problem with DTML had little to do with DTML syntax, nothing indicates that ZPT growing pains are going to turn ZPT into a monster. As long as we retain Python Scripts and evolve ZPT slowly, ZPT is in no danger of becoming a problem like DTML did. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more Zope2.6 fun: ZEO client death.
On Wed, 30 Jul 2003 17:21:51 +1000 Anthony Baxter [EMAIL PROTECTED] wrote: So I see ZEO clients here falling over all over the place under current 2.6 with: 2003-07-30T07:01:04 ERROR(200) ZEO uncaptured python exception, closing channel ZEO.zrpc.asyncRPC connected '' at 0xc57198 . . [Explanation of problem snipped] . This, to me, seems a showstopper for 2.6.2. We've been running a ZEO client / ZEO server setup using Zope 2.6.2b2,3 and 4 and not encountered this problem. Which ZEO version are you using? --andy. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] simpler TALES. (was Re: TALES idea: tuple unpacking)
On Tue, Jul 29, 2003 at 07:23:36PM -0300, Leonardo Rochael Almeida wrote: But right now the choice between adding or not the proposed TALES extensions is a choice between having to explain what all those python concepts mean before or after the poor template guy got confused why certain things don't work as expected: * Why must I use a tal:define=something here/getSomeObject and later a tal:content=something/someAttribute instead of just tal:content=here/getSomeObject/someAttribute. you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive). * Why does tal:content=request/form/items don't get me the items object that I'm expecting you lost me there. In order to get to the ideal world Paul wants (and that I want too), maybe we need to restrict the things that TALES can navigate. That would mean we'd need to chose between TALES path navigating dictionary keys or attribute access, but not both. Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']). Also, paths would not be able to call anything in the last segment. eh? so tal:content=here/some_method would no longer work? I don't really understand your proposal I'm afraid. On the other hand, we'd need to give python scripters the necessary tools, ex. before ZPT, I used to find it VERY anoying that I had to use the mapping attribute in DTML tags just because I couldn't create MyBrain objects thru python. PythonScripts should be able to generate the same kind of objects that ZCatalog and ZSQL queries generate. Not sure what you mean. You want to wrap Brains around something other than ZSQL results? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's TWITTY-PHYSICIAN! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TALES idea: tuple unpacking
Jim Penny wrote: Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ. The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary. Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument Because I'm not passing an argument to the SQL statement. In my implementation, the syntax is call:arg1,arg2,..., where each argument is required to be a variable name. Every prefixed path element operates upon the current traversal object, using the argument (if any) to the prefix. Here's a list that demonstrates: x/key:foo -- x['foo'] x/item:0 -- x[0] x/attr:foo -- x.foo x/call:foo -- x(foo) x/var:foo -- getattr(x, foo) or x[foo] (path traversal semantics) x/fmt:%.2f -- '%.2f' % x x/fmt:thousands_commas -- thousands_commas(x) Yes, alternative is very nice. Yes, it can be done with python:path(), or by refactoring the expression to an script. Yes, the alternatives are harder to read, or more work. Nu? I can't think of a way to implement my first example using python:path(), though you could certainly do it with a Script. The second example can be awkwardly rewritten by defining exists:data/stat and using it in a short-circuiting boolean expression such as have_stat and thousands_commas(data.stat) or 'No data.'. My point is that these prefixes allow a degree of precision, when necessary, that is not possible in current TALES without totally transforming the expression. Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application? I hope that the list above makes the consistency clearer. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
Paul Winkler wrote: you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive). I believe that his example referred to the case where the intermediate object must be called before path traversal can continue. Since the result of a path expression is called, if possible, the two-step define gets the job done. With prefixes, the simpler here/getSomeObject/call:/someAttribute gets the job done. * Why does tal:content=request/form/items don't get me the items object that I'm expecting you lost me there. request/form is a mapping, and traversal tries attribute access first, so you get request.form.items() rather than request.form['items']. Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']). Not quite. Attribute access invokes acquisition, while item access never does, so getattr(foo, 'bar.html') may succeed where foo['bar.html'] fails. Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, Jul 30, 2003 at 12:13:41PM -0500, Evan Simpson wrote: The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- they have a basic knowledge of data structures but they can't be taught to write a python script in about the same amount of time? you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary. That exception does smell a bit funny... having to say here/some_dict/item:0 just feels odd. But I can't remember ever using integers as dictionary keys so it's probably not worth fussing over. :-) I hope that the list above makes the consistency clearer. actually it does help a bit, thanks. hmm. It's not horrible :-) I'm just still on the fence about whether we really need it. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's BUTCHER BROMO-BOTTLE CAP! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
Evan Simpson wrote: With prefixes, the simpler here/getSomeObject/call:/someAttribute gets the job done. FWIW, I'd write this as here/call:getSomeObject/someAttribute. I suppose it's possible to support both. One interesting difference is that my syntax says both get an attribute and call it, while yours says only call it. Mine is a method call, while yours is a function call. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
On Wed, Jul 30, 2003 at 12:19:35PM -0500, Evan Simpson wrote: Paul Winkler wrote: you don't :) it's a convenience (less stuff to type if you access the object a lot) and/or an optimization (getSomeObject might be expensive). I believe that his example referred to the case where the intermediate object must be called before path traversal can continue. ah, i see. hm, well if getSomeObject is a Python Script, it's called anyway and it can only deal with someAttribute in its traverse_subpath anyway. Hm. Doesn't really matter - ObjectManager makes them equivalent anyway (except that some keys cannot be spelled as attributes, e.g. foo['bar.html']). Not quite. Attribute access invokes acquisition, while item access never does, so getattr(foo, 'bar.html') may succeed where foo['bar.html'] fails. Ugh. I don't know how I've been using zope 2 this long without noticing that item access doesn't acquire. But i just checked and by golly, you're right. I have to say, that's pretty horrible. :-) Is that documented anywhere? I've never seen it if so. And getattr(foo, some.string.that's.not.a.valid.python.varname) is just aesthetically bad. :-\ yay zope 2... principle of most surprise wins again :-( -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's OVERLY PADDLE SADIST! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
On Wed, Jul 30, 2003 at 02:06:13PM -0400, Shane Hathaway wrote: Evan Simpson wrote: With prefixes, the simpler here/getSomeObject/call:/someAttribute gets the job done. FWIW, I'd write this as here/call:getSomeObject/someAttribute. I suppose it's possible to support both. really? How? If you support evan's version, then yours means call whatever 'here' refers to, and pass getSomeObject as an argument. One interesting difference is that my syntax says both get an attribute and call it, while yours says only call it. Mine is a method call, while yours is a function call. How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's UN-LIBIDO OMEGA! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
Paul Winkler wrote: On Wed, Jul 30, 2003 at 02:06:13PM -0400, Shane Hathaway wrote: Evan Simpson wrote: With prefixes, the simpler here/getSomeObject/call:/someAttribute gets the job done. FWIW, I'd write this as here/call:getSomeObject/someAttribute. I suppose it's possible to support both. really? How? If you support evan's version, then yours means call whatever 'here' refers to, and pass getSomeObject as an argument. No. I can see how you interpreted it that way, though. call: is intended to be a method call, and Evan has provided a way to make it a function call also. In either case, you never pass any arguments. I see the expression x/call:y as call the method named 'y' of 'x'. If no 'y' is provided, as in x/call:, it means call 'x'. One interesting difference is that my syntax says both get an attribute and call it, while yours says only call it. Mine is a method call, while yours is a function call. How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions. If you need to pass arguments, use a Python expression. Python expressions are not on trial. If you need to pass exactly one argument, you can use a prefix that implies that. format:, as I've been using it, is one such prefix. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
Shane Hathaway wrote: FWIW, I'd write this as here/call:getSomeObject/someAttribute. I suppose it's possible to support both. One interesting difference is that my syntax says both get an attribute and call it, while yours says only call it. Mine is a method call, while yours is a function call. Mine also allows simple argument lists, and supports stuff like here/key:getSomeObject/call:/someAttribute. On the other hand, it has already confounded someone's intuition :-) Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 30 Jul 2003 12:13:41 -0500 Evan Simpson [EMAIL PROTECTED] wrote: Jim Penny wrote: Well, that is exactly why it will be more confusing to everyone. A python programmer is not expecting them to be different, and a non-programmer has no idea of what keys and indices are, much less how they differ. The explanation isn't that hard, at least for a user with a basic knowledge of data structures -- you usually use key: with a dictionary, and item: with a sequence. The exception is when you have an integer key in a dictionary. It is in fact not only hard to teach, it is impossible to use. Look, the ZPT programmer has no way of discovering whether the python programmer has returned a dictionary, a sequence, a Set, or anything else, much less what the key type is. Introspection is not available to a ZPT programmer. So, you are back to asking the python programmer, who just as well do the work. And why would I expect a ZPT person to have a basic knowledge of data structures? Eeep, gad no. The python is horrible. The prefix syntax is equally horrible, unfamiliar, and ambiguous! For example, why does call: not have an argument Because I'm not passing an argument to the SQL statement. In my implementation, the syntax is call:arg1,arg2,..., where each argument is required to be a variable name. Every prefixed path element operates upon the current traversal object, using the argument (if any) to the prefix. Here's a list that demonstrates: x/key:foo -- x['foo'] x/item:0 -- x[0] x/attr:foo -- x.foo x/call:foo -- x(foo) x/var:foo -- getattr(x, foo) or x[foo] (path traversal semantics) x/fmt:%.2f -- '%.2f' % x x/fmt:thousands_commas -- thousands_commas(x) Doesn't it strike you as odd that sometimes the prefix denotes parameterization, and sometimes it denotes application? I hope that the list above makes the consistency clearer. No, it actually makes it clearer, and worse. It is an interesting notation, kind of, but hugely irregular, and that you and Chris are talking about two quite different semantics on top of a similar syntax does not help things in the least. One by one: key: and item: need to be combined, as they cannot be practically used by the ZPT programmer as separate entities, due to lack of introspection. var: is semantically clear, but I suspect will confuse the hell out of non-programmers. Frankly, and I freely admit that I have not a clue to the implementational details, I would prefer that key:, item:, and var: all be a single entity, say index: x/index:'foo' -- x['foo'] x/index:span_of_int -x[span_of_int] x/index:foo-- x[foo] call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this? I assume that only positional parameters are permitted. With named parameters, this is the part I have fewest reservations about. Is there any reason to avoid parentheses however? Does using call: explicitly erase all magic name bindings (I hope so)? Why not x/call:(parameter_list)? There are several reasons to consider this. The primary one is that niladic calls are explicitly marked. Another reason, again with niladic calls is that x/call:()/foo makes is more clear that the foo attribute of x() is being requested, rather than that /foo is an argument to x. The final one is that it would probably permit much more general parameter lists, possibly including constants and/or named parameters. attr: looks clean enough. Combinations of attr: and call: made me think for a while, but, I don't see any obvious problems. fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where? Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix. Jim Penny Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
On Wed, Jul 30, 2003 at 02:29:45PM -0400, Shane Hathaway wrote: How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions. If you need to pass arguments, use a Python expression. Python expressions are not on trial. You said in another post: My feeling is that you should avoid mixing syntaxes in a single document. So I'm getting mixed messages from you. :-) I was bringing up a common case that results in mixing syntaxes, and which won't be avoidable unless the new call: prefix allows arguments. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's CLOWN OF THE MOUNTAINS! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
Paul Winkler wrote: On Wed, Jul 30, 2003 at 02:29:45PM -0400, Shane Hathaway wrote: How would you pass arguments in your version? I'd say that passing arguments accounts for a very large percentage of my need to use TALES python expressions. If you need to pass arguments, use a Python expression. Python expressions are not on trial. You said in another post: My feeling is that you should avoid mixing syntaxes in a single document. So I'm getting mixed messages from you. :-) They are consistent because neither is absolute. I'm tired of this. Do you have a better alternative to subpath prefixes? The constraints are tight: - You have to make calling explicit. It's important for Zope 3. - You don't get the implicit acquisition crutch anymore. It's important for Zope 3. - You have to provide an easy way to access APIs. It's important for Zope 3. - You have to provide a way to explicitly acquire. It's important for Zope 3! - You can't use Python statements in templates. - Everyone is going to argue over your solution for months. I've tried very hard to invent a way to solve the problems with path expressions without changing TALES. I can't. So I gave myself the flexibility of using just one character that was reserved anyway in path expressions, and the solution fell out. If you want to look for a solution, consider using *only* Python expressions--no path expressions. You'll get a lot of mileage that way, but at the expense of syntax clashes. Who knows, you might find a pretty good solution. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: TALES idea: tuple unpacking
On Wed, 30 Jul 2003 15:59:47 -0500 Evan Simpson [EMAIL PROTECTED] wrote: Several of your objections/suggestions involve the distinction between a string and a name, as in: x/index:'foo' -- x['foo'] x/index:span_of_int -x[span_of_int] x/index:foo-- x[foo] I'd rather not introduce additional punctuation (quotes or parens) But you've already crossed the Rubicon, :, ',', and % have been introduced as punctuation (yes, not matched, which does make a difference)! I am not opposed to this idea, per se, I am worried about the fact that it is so slippery slopish, and that it is so non-standard notationally. As a add-on product, I would say, go for it! As core functionality, it worries me. Further, this is an engineering trade-off. You are trading parsing simplicity by requiring extra programmer awareness - things which a python programmer is often not consciously aware of. I am trying to strongly point this out, so that you are prepared for the inevitable confusion later. if I can help it -- TAL and TALES both have a tradition of minimalist syntax, and it keeps parsing simple. Also, as soon as you add delimiters, you add quoting issues, and TALES has enough of those already. call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this? To keep things simple. There's a clearly visible slippery slope here, Yes, but named parameters can be very nice, especially working with databases, they let you match between form names, which are often very specific and database column names which are often more generic. And permitting constants keeps the programmer from an artificial requirement to define bind a constant to a name just to use it in a conditional section. I do understand the parsing issues, and can accept them, although I really would prefer named parameters be available, even if I have to give up constants. I strongly would urge you to use parentheses to denote functional application. Yes, I know there are alternative traditions, but they are much less common in practice. And the strongest one, RPN, was widely hated by 'the masses'. Does using call: explicitly erase all magic name bindings (I hope so)? I don't know what you mean, here. Well, grabbing missing parameters from request, and possibly (zope2) other places. fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where? 'fmt' is a quick-and-dirty implementation, and most likely to change. It was almost certainly a mistake to conflate the standard formatting functions with Python string formatting. I don't agree that it reverses the pattern, though -- to me, it's apply *this* formatting operation to the current object, much like 'key' is fetch *this* key from the current object. well, even if you persist in the mistaken ;-) notion that it is written key: x/key:y -- x[y] x/call:y -- x(y) x/fmt:y -- y(x) 'one of these things is not like the others...' Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix. 'prefix' refers to the syntax, not the operations. In my source code comments, I refer to prefixed path elements. A better name would be welcome :-) Hmm, maybe 'decorated path'. I am worried that prefix, postfix, and infix already have meaning, and this is more an infix language than a prefix language. But, I lost on 'snake thingy', so I will lose here to :-( Jim Penny ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)
On Wed, Jul 30, 2003 at 04:49:19PM -0400, Shane Hathaway wrote: I'm tired of this. Yes indeed :-) Do you have a better alternative to subpath prefixes? The constraints are tight: (snip) - You have to provide an easy way to access APIs. It's important for Zope 3. are you talking about things like z3 services? and/or zope 2 API stuff like foo.objectItems? - You have to provide a way to explicitly acquire. It's important for Zope 3! - You can't use Python statements in templates. right, expressions only... - Everyone is going to argue over your solution for months. really :-) I've tried very hard to invent a way to solve the problems with path expressions without changing TALES. I can't. So I gave myself the flexibility of using just one character that was reserved anyway in path expressions, and the solution fell out. If you want to look for a solution, consider using *only* Python expressions--no path expressions. You'll get a lot of mileage that way, but at the expense of syntax clashes. Who knows, you might find a pretty good solution. I think this is what I'm going to investigate. Who knows, I might find only bad solutions :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE SCIENTIFIC KING LEAR ! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more Zope2.6 fun: ZEO client death.
Jim and Andrew hit the nail on the head - excessive cleverness with vendor branches here meant that the ZEO directory had ZEO1 installed. Updating it by hand to ZEO2 hasn't made all good and happy, though - the ZEO/start.py includes import ThreadedAsync.LoopCallback at the top of the file, but the sys.path magic that makes this available is inside the main() function. Moving the import to the line after the sys.path magic fixes this. I'm now getting a failed import for ZODB.utils.oid_repr, which suggests that I'm going to need to update the ZODB installation here from the one that's in 2.6.2. :-/ -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more Zope2.6 fun: ZEO client death.
Anthony Baxter wrote Updating it by hand to ZEO2 hasn't made all good and happy, though - the ZEO/start.py includes import ThreadedAsync.LoopCallback at the top of the file, but the sys.path magic that makes this available is inside the main() function. Moving the import to the line after the sys.path magic fixes this. I'm now getting a failed import for ZODB.utils.oid_repr, which suggests that I'm going to need to update the ZODB installation here from the one that's in 2.6.2. :-/ Ok, this was easy - Zope2.6 requires the ZODB3-3_1-branch ZEO code. The previous ThreadedAsync import fix still needs to be applied, though... Anthony ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
