[Zope3-dev] attr name space (was: RFC: abolishing python: expressions)

2005-12-30 Thread Alexander Limi
On Thu, 29 Dec 2005 15:49:46 +0100, Philipp von Weitershausen [EMAIL PROTECTED] wrote: I think it would be quite possible to do explicit key or attribute lookup with TALES, e.g.: foo/attr:bar (for foo.bar) foo/key:bar (for foo['bar']) foo/item:1(for foo[1]) This reminds me of

[Zope3-dev] Re: attr name space

2005-12-30 Thread Philipp von Weitershausen
Alexander Limi wrote: This reminds me of a thing Steve Alexander and myself talked about when working together on a project using Zope 3 a while back: One of the ugliest and most error-prone parts of TAL is its handling of multiple attributes: a tal:attributes=href some/url;

Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)

2005-12-30 Thread Andreas Jung
--On 30. Dezember 2005 08:22:18 -0700 Jeff Shell [EMAIL PROTECTED] wrote: The same would probably be relevant for tal:defines, something like: div define:mammals=here/getMammals define:fish=here/getFish / - It looks nice! :) That's relative. It would call it: syntactic

Re: [Zope3-dev] RFC: abolishing python: expressions in ZPT TALES

2005-12-30 Thread Fred Drake
On 12/29/05, Jeff Shell [EMAIL PROTECTED] wrote: in the picture. But there are still little situations where Python expressions are handy, especially on big-macro templates where there's not a backing view. I'm not advocating programming in page templates, This points out where change is

Re: [Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES

2005-12-30 Thread Andrew Sawyers
On Thu, 2005-12-29 at 15:40 +0100, Andreas Jung wrote: What I am saying: don't take away feature that are useful for a particular kind of coders and for a particular way of coding. Don't take away a feature _just_ to enforce a certain way to do programming. +1 to Andreas. -1 to the

Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)

2005-12-30 Thread Fred Drake
On 12/30/05, Jeff Shell [EMAIL PROTECTED] wrote: - the TAL namespace had a limited and proper list of attributes. A very limited set of names that could be (theoretically) validated with standard XML tools. This should probably remain a goal, but I don't think it's as big a deal as the

Re: [Zope3-dev] attr name space

2005-12-30 Thread Andreas Jung
--On 30. Dezember 2005 11:50:16 -0500 Jim Fulton [EMAIL PROTECTED] wrote: I'm gonna stay out of this except to note that this discussion should be happening on the ZPT list (zpt@zope.org), as it affects much more than Zope 3 (or even Zope for that matter). Wasn't the ZPT list considered

Re: [Zope3-dev] attr name space

2005-12-30 Thread Fred Drake
On 12/30/05, Andreas Jung [EMAIL PROTECTED] wrote: Wasn't the ZPT list considered obsolete some time ago? No. The ZIP list is dead. I think there was a suggestion that the ZPT list should be closed, but I disagreed with that since there are a number of ZPT users outside of Zope, including

Re: [Zope3-dev] attr name space

2005-12-30 Thread Jim Fulton
Andreas Jung wrote: --On 30. Dezember 2005 11:50:16 -0500 Jim Fulton [EMAIL PROTECTED] wrote: I'm gonna stay out of this except to note that this discussion should be happening on the ZPT list (zpt@zope.org), as it affects much more than Zope 3 (or even Zope for that matter). Wasn't the

Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?

2005-12-30 Thread Shane Hathaway
Philipp von Weitershausen wrote: page 204, Example 12.24, line 17: Using the ``write()`` method of HTTP-based responses does not provide a performance advantage in Zope X3 3.0 and 3.1 and is not supported anymore in Zope 3.2 and higher. I would like to point out that response.write()

Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)

2005-12-30 Thread Dieter Maurer
Alexander Limi wrote at 2005-12-30 11:22 +0100: ... One of the ugliest and most error-prone parts of TAL is its handling of multiple attributes: a tal:attributes=href some/url; title some/title; / Why is this more ugly or error prone as your proposal? ... This provides

Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?

2005-12-30 Thread Shane Hathaway
Philipp von Weitershausen wrote: Shane Hathaway wrote: So I fully agree that the original write() should go (in fact I suppose it's gone already), but to say there was no performance advantage is imprecise. I spent a fair amount of time making write() fast, with some success. Interesting.

Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?

2005-12-30 Thread Shane Hathaway
Shane Hathaway wrote: Philipp von Weitershausen wrote: So using write() once doesn't at all seem like an advantage over simply returning the data... The interesting part is behind the scenes. If the response is large enough (it's an adjustable threshold), the response transparently gets

Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)

2005-12-30 Thread Marius Gedminas
On Fri, Dec 30, 2005 at 11:22:56AM +0100, Alexander Limi wrote: This reminds me of a thing Steve Alexander and myself talked about when working together on a project using Zope 3 a while back: One of the ugliest and most error-prone parts of TAL is its handling of multiple attributes:

Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?

2005-12-30 Thread Jim Fulton
Shane Hathaway wrote: Shane Hathaway wrote: Philipp von Weitershausen wrote: So using write() once doesn't at all seem like an advantage over simply returning the data... The interesting part is behind the scenes. If the response is large enough (it's an adjustable threshold), the

Re: [Zope3-dev] (zope/app/cache/ram.py) class Storage's cleanup problem.

2005-12-30 Thread Simon Hang
Hi Stephan, Is these code all right? Regards, SimonOn 11/13/05, Simon Hang [EMAIL PROTECTED] wrote: Thanks Stephan, Here is the test:(test_ramcache.py) class TestStorage(TestCase): def test_getEntry(self): --snipped-- def test_getEntry_do_cleanup(self): from zope.app.cache.ram import