[Zope-dev] more Zope2.6 fun: ZEO client death.

2003-07-30 Thread Anthony Baxter
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

Re: [Zope-dev] more Zope2.6 fun: ZEO client death.

2003-07-30 Thread Anthony Baxter
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

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Christopher Boomer
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

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Shane Hathaway
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

Re: [Zope-dev] more Zope2.6 fun: ZEO client death.

2003-07-30 Thread Andrew Sydelko
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 . .

Re: [Zope-dev] simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Paul Winkler
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

[Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Evan Simpson
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

[Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Evan Simpson
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.

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Paul Winkler
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?

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Shane Hathaway
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,

[Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Paul Winkler
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

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Paul Winkler
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?

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Shane Hathaway
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.

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Evan Simpson
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

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Jim Penny
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

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Paul Winkler
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

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Shane Hathaway
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

[Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Evan Simpson
Jim Penny wrote: And why would I expect a ZPT person to have a basic knowledge of data structures? In my view, this whole idea is primarily aimed at programmers. I fully expect that non-programmer ZPT people will be able to ignore this stuff, apart from being handed a small set of idioms by the

Re: [Zope-dev] Re: TALES idea: tuple unpacking

2003-07-30 Thread Jim Penny
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

Re: [Zope-dev] Re: simpler TALES. (was Re: TALES idea: tuple unpacking)

2003-07-30 Thread Paul Winkler
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

Re: [Zope-dev] more Zope2.6 fun: ZEO client death.

2003-07-30 Thread Anthony Baxter
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,

Re: [Zope-dev] more Zope2.6 fun: ZEO client death.

2003-07-30 Thread Anthony Baxter
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