[Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
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 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; title some/title; / etc. We looked at having a separate namespace for these kinds of statements. The above code would then be: a attr:href=some/url attr:title=some/title / thus doing away with the need for semicolons and the should the last line have a semicolon or not confusion. The same would probably be relevant for tal:defines, something like: div define:mammals=here/getMammals define:fish=here/getFish / This provides the following benefits: - Easier to parse for XML tools (no semicolons with any meaning) - More consistent syntax, no need to learn a special way to separate several attributes/defines - It looks nice! :) What do y'all think? For the record, I'm also for getting rid of the python: stuff in TAL, but only if we can solve the common use cases others have identified earlier in this discussion. Making ZPT carry less smarts and preferrably get it a bit faster would be very welcome in my universe. :) -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: attr name space
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; title some/title; / etc. We looked at having a separate namespace for these kinds of statements. The above code would then be: a attr:href=some/url attr:title=some/title / thus doing away with the need for semicolons and the should the last line have a semicolon or not confusion. The same would probably be relevant for tal:defines, something like: div define:mammals=here/getMammals define:fish=here/getFish / This provides the following benefits: - Easier to parse for XML tools (no semicolons with any meaning) - More consistent syntax, no need to learn a special way to separate several attributes/defines - It looks nice! :) It's especially much easier to format with a lot less whitespace... What do y'all think? +1 Steve presented me with that idea once too and I remember I had some negative feelings about it. I don't remember what they were, though :). I'd suggest that the namespace prefixes be talattr and taldefine just to be clear on what they belong too. Of course, I'd prefer if ZPTs would stop magically assuming certain namespace prefixes completely. Btw, we also need this for i18n:attributes which I guess would become i18nattr:attr. For the record, I'm also for getting rid of the python: stuff in TAL, but only if we can solve the common use cases others have identified earlier in this discussion. Making ZPT carry less smarts and preferrably get it a bit faster would be very welcome in my universe. :) I've tried to answer the three most important points of criticism in a blog entry: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_29_rocky-vi-one-man-against Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
--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 sugar. -aj pgpum1nYYWhKO.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: abolishing python: expressions in ZPT TALES
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 really needed (rather than just debated): templates used to provide macros don't have a place for Python code. That's a problem that's more in need of a solution than determining whether we like python: expressions. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: abolishing python: expressions in ZPT TALES
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 proposal. Andrew ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
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 ordering problem. - XML processing, if I recall correctly, does not cover ordering of tag attributes, nor gives them any significance. You couldn't have 'attr:title' have any dependency on 'attr:href', for example. That's correct; attributes do not have order in the XML information set. As a result, there are a limited list of TAL keywords with a well defined order of execution. How would these namespaces impact that? When doing proper XML processing with TAL, would the 'attr' and 'defines' and other namespaces all need to be explicitly loaded? We could easily say that each of these namespaces is processed at a certain point in the evaluation order; that's easy. Defining the order of processing within any one of these namespaces could be done on a strictly arbitrary basis (sorted by attribute name, for example), but remains arbitrary. This would lead to unsavory practices, like naming defines to control the order of evaluation rather than to express what's stored in them. I can't speak for others, but order of evaluation is often important when I have more than one define on a single element. The only example namespace I can think of that behaves this way is the xmlns: namespace, and that's also special in that the prefix is frozen. It's dealing with a chicken-and-egg problem, which we don't need to do. More namespaces increases the chance of namespace collision. I'm not sure what this means; use whatever prefixes you want. All this said, I understand Alex's desire to avoid long piles of stuff in attribute values; it's not very common to have several lines of stuff in an attribute. In most situations where substantial text is needed in an attribute, the attribute value is a reference (often via URL) to some other resource. But for what we're doing in TAL, that doesn't make much sense: the template becomes harder to understand and maintain, and the volumn of text is unlikely to be more than a handful of lines. I'm glad he's thinking about how we can improve the situation. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space
--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 obsolete some time ago? -aj pgp35d5UMHk2k.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space
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 users of alternate implementations. Jim's right; this should be on the ZPT list. I wish I'd thought of that before I posted. I'll send a heads-up to the ZPT list. I've CC'd that list on this note, and will post a brief summary and archive pointers to that list. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space
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 ZPT list considered obsolete some time ago? Really? I don't remember hearing anything like that. Why would it be obsolete? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?
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() originally did provide an advantage by transparently putting large output into a temporary file rather than holding it in RAM. This is a performance advantage for highly concurrent sites sending multiple megabytes over relatively slow links, since it allows precious database threads to be freed while the kernel optionally pages out the response until the client finishes downloading. However, the original response.write() does not provide a performance advantage in most situations because the original write() API pushes data; the data has nowhere to go except some temporary storage until the client is ready for it. Temporary storage is somewhat expensive. Pulling data instead is likely to provide a performance benefit in more situations. 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. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
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 the following benefits: - Easier to parse for XML tools (no semicolons with any meaning) For the XML tools, the semicolons are just part of an attribute value. They do not have any problems with them... - More consistent syntax, no need to learn a special way to separate several attributes/defines Learning that ; separates assignments and that ;; escapes seems not to be a big burden. - It looks nice! :) For me, it does not look nicer than what you want to replace. What do y'all think? -1 -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?
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. Where exactly did this effort of making write() fast go into? Looking at X3 3.0's response.write() method, I basically see: def write(self, string): self._outstream.write(string) 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 sent to a temporary file. If the load on the server doesn't allow all the responses to fit in RAM, temporary files are an advantage because they allow the kernel to help manage the memory. (CPython's manner of using memory makes it hard for the kernel to page most memory held by Python processes.) However, as I said earlier, there was only advantage if a lot of conditions were met. Those conditions were often met by Zope Corporation customers. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?
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 sent to a temporary file. If the load on the server doesn't allow all the responses to fit in RAM, temporary files are an advantage because they allow the kernel to help manage the memory. (CPython's manner of using memory makes it hard for the kernel to page most memory held by Python processes.) Now that I've brought more of this issue back into my head, I remember that the advantage I just spoke of is independent of response.write(). However, there was still an advantage if a response is large enough that it doesn't comfortably fit in RAM. response.write() allowed the application to write the response in pieces, giving the kernel an opportunity to swap out the response data immediately rather than thrash. If Zope 2's ZServer didn't have this feature, zope.org would crawl even worse than it does now. I know this because of some zope.org debugging sessions. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
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: a tal:attributes=href some/url; title some/title; / etc. We looked at having a separate namespace for these kinds of statements. The above code would then be: a attr:href=some/url attr:title=some/title / How would you express my_xml_element tal:attributes=xlink:href some/url; xlink:title some/title; / ? AFAIR if you use the XML Namespaces spec, you can only have one ':' in an attribute name, so this would be invalid: my_xml_element attr:xlink:href=some/url attr:xlink:href=some/title / The same would probably be relevant for tal:defines, something like: div define:mammals=here/getMammals define:fish=here/getFish / You can do things like div tal:define=foo view/foo; bar foo/bar; baz python:bar and 'something' or 'somethingelse'; qux string:my_class $baz / because the ordering of definitions is explicit. How would you specify the order of definitions if you used separate attributes in the define: namespace? Attributes have no order in XML. Marius Gedminas -- C++ is a loaded machine gun helpfully pointed at your feet with the safety off. -- ChaosDiscord on Slashdot signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: URGENT RFC: Is anyone using response.write in Zope 3?
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 response transparently gets sent to a temporary file. If the load on the server doesn't allow all the responses to fit in RAM, temporary files are an advantage because they allow the kernel to help manage the memory. (CPython's manner of using memory makes it hard for the kernel to page most memory held by Python processes.) Now that I've brought more of this issue back into my head, I remember that the advantage I just spoke of is independent of response.write(). However, there was still an advantage if a response is large enough that it doesn't comfortably fit in RAM. response.write() allowed the application to write the response in pieces, giving the kernel an opportunity to swap out the response data immediately rather than thrash. If Zope 2's ZServer didn't have this feature, zope.org would crawl even worse than it does now. I know this because of some zope.org debugging sessions. You are confusing Zope 2 and Zope 3. Zope 2's response.write does handle large output effciently, Zope 3's did not. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] (zope/app/cache/ram.py) class Storage's cleanup problem.
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 Storage
s = Storage(cleanupInterval=300, maxAge=300)
object = 'object'
key = ('view', (), ('answer', 42))
value = 'yes'
s.setEntry(object, key, value)
s._data[object][key][1] = time() - 400
s.lastCleanup = time() - 400
try:
s.getEntry(object, key)
except KeyError:
pass
else:
raise cleanup not called
def test_setEntry(self): --snipped--
On 11/12/05, Stephan Richter [EMAIL PROTECTED]
wrote:
On Tuesday 01 November 2005 05:10, Simon Hang wrote: Dear all, I'm happen to find out call Storage only do cleanup when new Entry comes and do nothing when entries get from storage. So entries will be next
expired if there are only read activities.I agree with your analysis and solution. If you provide a test for the fix,I'll check it in. If you cannot write a test, please add least add an issueto the issue collector.
Regards,Stephan--Stephan RichterCBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
