[Zope3-dev] zc.testbrowser.real depends on python 2.5
Looks like zc.testbrowser 1.0a1 has a small dependency on Python 2.5. I got this error while playing with zc.testbrowser.real: browser.getForm(id='oc-login-form') Traceback (most recent call last): File stdin, line 1, in ? File /home/pw/tbtest/lib/python2.4/zc.testbrowser-1.0a1-py2.4.egg/zc/testbrowser/real.py, line 315, in getForm if index is None and not any([id, name, action]): NameError: global name 'any' is not defined This is easy to hack around, but it's probably worth documenting the dependency... -- Paul Winkler ___ 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: What does python 3000 mean for zope?
On Tue, Sep 11, 2007 at 12:49:23AM -0400, Paul Winkler wrote: On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote: Has there been a strong statement that there won't be a Python 2.7 and beyond? Will Python 2.x be actively killed off? Quite the opposite, Guido proposed last year to do 2.7, 2.8, and 2.9. After that it's not clear to me. FYI, I asked about this on comp.lang.python. New thread here: http://groups.google.com/group/comp.lang.python/browse_frm/thread/abc75862abe56d6a/3ecd2db9a2cb6b26?hl=en#3ecd2db9a2cb6b26 -- Paul Winkler http://www.slinkp.com ___ 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: What does python 3000 mean for zope?
On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote: Has there been a strong statement that there won't be a Python 2.7 and beyond? Will Python 2.x be actively killed off? Quite the opposite, Guido proposed last year to do 2.7, 2.8, and 2.9. After that it's not clear to me. In the discussion on Python 2.x and 3.x compatibility, substitute the word Zope for Python and think of the irony. I'm still waiting for the announcement of Python Five :-) -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Is there an alternative to zdaemon?
On Fri, Dec 22, 2006 at 05:04:37PM -0500, Jim Fulton wrote: Sascha Ottolski wrote: And the python coded Supervisor2 made by Chris McDonough http://www.plope.com/software/supervisor2/ This is interesting. We've been using supervisor (previous version) for all our zope applications for a year or so. Works as advertised, pretty easy to set up. At my previous job, we used daemontools, which was OK, except we never found a solution to the problem of I want to get email notifications when the system is restarting unexpectedly, but I don't want my mail to get a DOS attack when the system can't start successfully so it keeps restarting forever. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Is there an alternative to zdaemon?
On Fri, Dec 22, 2006 at 11:38:33PM +0100, Sascha Ottolski wrote: At my previous job, we used daemontools, which was OK, except we never found a solution to the problem of I want to get email notifications when the system is restarting unexpectedly, but I don't want my mail to get a DOS attack when the system can't start successfully so it keeps restarting forever. hmm, what about: let the run script touch or write some status file; the very same script would send an email on a normal restart, but may stop to do so if the status file is to new. hmm, thinking further, the script could even delay or block the restart, if desired. i guess the run script could also be written in python. Sure, but it's such a common need that ideally I'd like that to be taken care of for me :-) supervisor normally gives up after some number of restart attempts, which is fine with me. -- Paul Winkler http://www.slinkp.com ___ 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: Can an adapter find out what name it was registered for?
On Tue, Nov 28, 2006 at 06:12:19PM +, Chris Withers wrote: Is there a python-only way to register adapters instead of in ZCML and, if it exists, is it safe to use in conjunction with the normal zcml dances? There's always a way :) You could just do what the directive does - call the adapter() function which used to be in zope.app.component.metaconfigure but now lives in zope.component.zcml. I haven't done it but AFAICT it should work safely. It's sometimes instructive to look at how directives are implemented. Find the meta.zcml file that declares the directive, and that'll tell you what module contains the schema and handler for that directive. The handler does the work. -- Paul Winkler http://www.slinkp.com ___ 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: adapter registration - sort of works :-S
On Thu, Nov 16, 2006 at 10:21:09AM +0100, Philipp von Weitershausen wrote:
How would I _really_ return None from an adapter?
You don't. You call the adaption with a default value (e.g. None) to
cover for the coudln't adapt case:
getAdapter('moo', DateTime, None)
That doesn't work, getAdapter() doesn't have a default arg.
I think what you meant is:
queryAdapter('moo', DateTime, default='xyz')
'xyz'
--
Paul Winkler
http://www.slinkp.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] PyCon 2007 web frameworks panel
On Tue, Oct 31, 2006 at 07:54:41PM +0100, Martijn Faassen wrote: I'm happy to see you do this. I can't make it to that PyCon, unfortunately. As to representing other people's opinion: Talk about Grok. Better yet, show Grok code. By that time, we should be quite a way with it, supporting most Zope 3 features out of the box. I think Grok does quite well in the simplicity and developer productivity departments. Simplicity and developer productivity is something that is heavily advocated for some other Python web frameworks. Zope 3 had a bit of trouble to keep up with that. With Zope Grok, no more trouble. This sounds like something that could stand being talked about in public more often... I've never heard of Zope Grok :) -- Paul Winkler http://www.slinkp.com ___ 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: another layers quicky?
On Tue, Oct 17, 2006 at 05:40:51PM +0100, Chris Withers wrote: Philipp von Weitershausen wrote: ? No. Who said you should do that? http://zopewiki.org/TestLayersHowTo ... and more authoritatively, a number of tests in zope/testing/testrunner-ex use strings. Prior to the introduction of testrunner-layers-api.txt, there wasn't much else to go on. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
On Tue, Oct 17, 2006 at 11:30:46AM +0100, Chris Withers wrote: Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? I noticed the same thing when I wrote my zopewiki page (http://zopewiki.org/TestLayersHowTo) but it looks like new-style classes should work now, judging by this svn log message: r68925 | Zen | 2006-06-30 07:49:37 -0400 (Fri, 30 Jun 2006) | 3 lines Fix ordering of testSetUp and testTearDown calls, and allow new style classes to be used as Layers by explicitly ignoring the object baseclass. Also, at the time I wrote that page (in July), I wasn't aware of zope/testing/testrunner-layers-api.txt which would've saved me some trial and error. That may be the narrative you're looking for? I'll update the zopewiki page with a reference to that doc. Looks like that file is shipped with Zope 2.10.0 and 2.9.5, but it wasn't in 2.9.4. I haven't been living on the bleeding edge lately so I didn't see it. -- Paul Winkler http://www.slinkp.com ___ 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: zope.testing.testrunner: issue with remove_stale_bytecode
On Wed, Oct 11, 2006 at 05:56:41PM -0400, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Wichert Akkerman wrote: Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? No, because you may have intended to remove the module. Marking the directories containing the sourceless .pyc files as readonly would be a reasonable workaround: if your forgot the '-k', the testrunner would just whine and halt. Good point. Thanks, Tres. I think Chris' idea might have merit too, but I don't really have time to hack on testrunner. For now, I'm just going to run tests with a wrapper script. -- Paul Winkler http://www.slinkp.com ___ 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.testing.testrunner: issue with remove_stale_bytecode
On Tue, Oct 10, 2006 at 08:13:23PM -0400, Jim Fulton wrote: Paul Winkler wrote: Posting this here because the code in question lives in zope.testing... After accidentally nuking my mxODBCZopeDA installation simply by running bin/zopectl test in a zope 2.9 instance, I quickly concluded: There is no bug. testrunner.py is behaving exactly as designed. Stale bytecode causes spurious test failures due to finding compiled modules where source modules have been deleted. Therefore, we should delete it by default. But this conflicts with third parties being able to deliver bytecode instead of source, which is a standard python feature (if not common in the zope world). Since we can't tell the difference between stale and we never had source in the first place, deleting bytecode is arguably surprising and overly invasive. I guess it comes down to choosing the lesser of two evils. Which is worse? Confusing test errors caused by stale bytecode, or a test run having the power to break your instance with the default options? I don't see a third path. ideas? opinions? See: http://www.python.org/pypi/zope.testing#running-without-source-code Thanks for the pointer. AFAICT the current docs confirm my understanding. --usecompiled would be useful if I wanted to run tests in a package for which I didn't have source. That's not the case here. All I need is -k, --keepbytecode. I think the current default behavior sucks, but I think changing it would just suck differently :-( -- Paul Winkler http://www.slinkp.com ___ 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.testing.testrunner: issue with remove_stale_bytecode
On Wed, Oct 11, 2006 at 11:43:13PM +0200, Wichert Akkerman wrote: Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? No. It means one of two things, if you read the thread carefully. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
Posting this here because the code in question lives in zope.testing... After accidentally nuking my mxODBCZopeDA installation simply by running bin/zopectl test in a zope 2.9 instance, I quickly concluded: There is no bug. testrunner.py is behaving exactly as designed. Stale bytecode causes spurious test failures due to finding compiled modules where source modules have been deleted. Therefore, we should delete it by default. But this conflicts with third parties being able to deliver bytecode instead of source, which is a standard python feature (if not common in the zope world). Since we can't tell the difference between stale and we never had source in the first place, deleting bytecode is arguably surprising and overly invasive. I guess it comes down to choosing the lesser of two evils. Which is worse? Confusing test errors caused by stale bytecode, or a test run having the power to break your instance with the default options? I don't see a third path. ideas? opinions? -- Paul Winkler http://www.slinkp.com ___ 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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
On Wed, Jun 28, 2006 at 11:47:28AM +0200, Christian Theune wrote:
I'm very much against relaxed date/time format checking. I tend to
give my user the exact format that is expected and fail otherwise. All
the guessing in the past led to bad bad errors because the field order
the user entered was syntactically compatible but had a semantically
different meaning.
E.g.
02/05/2005 and 02.05.2005 are two different things.
As another data point, I recently stumbled on this quirk
of zope 2's DateTime class:
DateTime('2006/01/01').timezone()
'US/Eastern'
DateTime('2006/01/01').timeTime()
1136091600.0
DateTime('2006-01-01').timezone()
'GMT+0'
DateTime('2006-01-01').timeTime()
1136073600.0
AFAICT, this is a feature, not a bug.
--
Paul Winkler
http://www.slinkp.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
On Sun, Jun 18, 2006 at 02:29:14PM -0400, Christian Theune wrote: Philipp von Weitershausen wrote: Andreas Jung wrote: My recommendation: 1 yr deprecation period as it is now 1 yr + X maintenance period for older branches. +1 Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore... Is there any chance we can create an overview page that reflects the status of what changes need to be ported where and what the status of that branch is? Maybe some kind of matrixy-thingy? +1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula. as others have observed, bugfixing is easier when you have fewer branches to patch and test... -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
On Sun, Jun 18, 2006 at 08:30:58PM +0200, Lennart Regebro wrote: On 6/18/06, Paul Winkler [EMAIL PROTECTED] wrote: +1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula. Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now. OK, but just to clarify: Will we stop having to backport bugfixes to 2.8 when 2.10 final is released? But we need to backport bugfixes during the 2.10 beta cycle? Is this policy written down somewhere? -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [z3-five] Re: Patch for testbrowser.py
On Fri, Apr 21, 2006 at 04:07:43PM +0200, Daniel Nouri wrote:
The relevant code in Zope2's ZPublisher.HTTPResponse.__str__:
# ... we just built a headersl list using self.heders
if self.cookies:
headersl = headersl+self._cookie_list()
headersl[len(headersl):] = [self.accumulated_headers, body]
return '\n'.join(headersl)
Maybe this can shed some light on whether we want to include that patch.
As an aside:
What's with assigning to headersl[len(headersl):] instead of calling
headersl.extend(...)?
I've seen this idiom a couple of times and I always wonder
why, it's much less readable IMO.
I doubt it's supposed to be an optimization, since this code runs only
once per request; anyway, the two idioms are about equivalent in speed
AFAICT.
If it were in a performance-sensitive loop, a bit faster
and still quite readable would be:
headersl += [self.accumulated_headers, body]
timeit confirms this, here on python 2.4.2:
import timeit
slicer = timeit.Timer('x[len(x):] = [4,5,6]', 'x=[1,2,3]')
adder = timeit.Timer('x += [4,5,6]', 'x=[1,2,3]')
extender = timeit.Timer('x.extend([4,5,6])', 'x=[1,2,3]')
n = 100)
slicer.timeit(n)
2.6605889797210693
extender.timeit(n)
2.5256669521331787
adder.timeit(n)
1.9388060569763184
--
Paul Winkler
http://www.slinkp.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Testing logs
So I was looking at zope.testing.loggingsupport as a way to replace CMFCore.tests.base.testcase.LogInterceptor, which exists for a similar purpose. Duplication is bad and all that. The thing that struck me about loggingsupport.InstalledHandler is that you really want to create one during setUp() and uninstall it during tearDown(); otherwise if a test fails the handler will stay active for the rest of the test run and you could end up with a whole bunch of them. (Maybe that's harmless.) The one thing that struck me is that unlike the old zLOG-based LogInterceptor, there's no easy way to disable other handlers. e.g. I typically don't want to see expected log spew on stdout when running tests, it's distracting. LogInterceptor did that, true to its name it swallowed all logging until you told it to stop - but of course this meant you had to be even more careful to always restore the old state of affairs when you were done with it. Don't want one error to kill all logging for the rest of the run! (But then there's also zope.testing.loghandler, which seems to be a very similar approach to loggingsupport with a couple of extra convenience methods and the same problem w.r.t. the need to be sure to get rid of it after tests. Maybe Jim didn't notice this one when he wrote loggingsupport? afaict loghandler is older). I don't really have a question. Just wondering if anybody has any thoughts on the one true way to deal with this stuff properly. -- Paul Winkler http://www.slinkp.com ___ 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: [Zope-CMF] Fighting the Zope 2.9 testrunner
On Wed, Mar 22, 2006 at 06:25:41PM +0100, Martijn Faassen wrote: Anyway, a release and the development situation looking similar helps people actually work on the same codebase and structure, and not having to learn different ways of doing things as soon as they switch. Forcing context switches on people isn't a good idea. +1 -- Paul Winkler http://www.slinkp.com ___ 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: a plan for widgets?
On Thu, Mar 16, 2006 at 11:38:02AM -0500, Tres Seaver wrote: zcml:ktupema_necro_halogo eh? http://www.google.com/search?hl=enlr=q=ktupema+necro+halogobtnG=Search Your search - ktupema necro halogo - did not match any documents. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On Mon, Mar 13, 2006 at 04:14:08PM -0700, Shane Hathaway wrote: You're aware of the DRY principle, right? ZCML is repetitive, and repetitive is wrong. We tend to think that repetition is *always* wrong, but in other fields there are cases in which it depends who the reader is, and how the repetition is expressed. One thing I learned in my long-ago days as a music student is that the least repetetive way to write a score is often the most difficult to sight-read. The stupidest, most repetitive way to write the score is very easy to read; it's completely linear, so the reader can't get lost. You can notate repetition easily enough, and make the score more compact, at the expense of requiring the reader to mentally construct the linear model and maintain more mental state while playing. I have no idea whether any of that applies to ZCML, so I'll re-lurk now. -- Paul Winkler http://www.slinkp.com ___ 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: A Take on the Hello World Acid Test - from Mandatory Viewing
On Thu, Mar 09, 2006 at 02:38:48PM +0100, Paul Everitt wrote: One little Python script, maintained as part of the standard distribution, referred to ubiquitously as the right way to start, would have more impact on Zope adoption than nearly any other software activity (save, perhaps, for zope.bobo). All IMO, of course. We do already have bin/pyskel, which is useful as far as it goes, but that's of course not very far. I'd really like to see some more scaffolding. Unfortunately there are so many use cases, we could easily get bogged down on the details. For example, I can imagine: * Create a skeletal package structure. input: name of package, e.g. foo creates (if they don't exist): lib/python/foo lib/python/foo/__init__.py lib/python/foo/browser lib/python/foo/browser/__init__.py lib/python/foo/tests/ lib/python/foo/tests/__init__.py lib/python/foo/tests/test_foo.py lib/python/foo/ftests/ lib/python/foo/ftests/__init__.py lib/python/foo/ftests/test_foo.py etc/package-includes/foo-configure.zcml ? lib/python/foo/configure.zcml ? lib/python/foo/browser/configure.zcml ? * Given interface(s), generate a skeletal class and supporting files. input: lib/python/foo/interfaces.py creates (but warns and exits if files exist): lib/python/foo/foo.py create an interface test in lib/python/foo/tests/test_foo.py add some wiring to lib/python/foo/configure.zcml options: create a view class in lib/python/foo/browser/views.py? create a template for that view class? create an edit form using a template? or zope.formlib? or what? create an add form using zope.formlib? or a template? or...?? Lots of options here! Probably the best initial approach would be to make it modest but trivially extensible so you could write scripts that leverage it but do what *you* want for *your* project. Several obvious candidates for implementing stuff like this: Skeletor https://svn.plone.org/svn/collective/skeletor/trunk/ Paste Script and Paste Templates http://pythonpaste.org/script/developer.html#templates -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mandatory Viewing!
On Tue, Mar 07, 2006 at 11:27:48AM -0700, Shane Hathaway wrote: Part of the problem is that Zope 3 makes too great a distinction between developers and scripters. Successful scripters become developers, and developers often act as scripters. +1. The distinction is arbitrary and fluid. I think the use cases need to see scripters and developers as the same people. The other Python web frameworks seem to be oriented this way and they've had a lot of success. Yes. Whatever we do with scripting in zope 3, I want it to look as much as possible like vanilla python code on the filesystem. This is why IMO scripts in zope 2 are such an evolutionary dead end: - magic global bindings. - the print ; return printed idiom. - restricted imports. All of those create stop energy when you want to refactor some code between a script and product code. The first two teach newbies to rely on features that do not exist anywhere else in the python world, which I think was a bad design mistake. btw, I must note that TTW != scripting. Scripting does not mandate working through the web, and using a browser as (part of) your environment does not necessarily imply scripting. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
On Sun, Mar 05, 2006 at 04:04:48PM -0500, Benji York wrote: Geoff Davis wrote: * What can we learn from Rails / Django / TurboGears? Fun presentation along those lines: http://oodt.jpl.nasa.gov/better-web-app.mov One of the best put together movies I've seen. Really interesting stuff. I was struck by the way he presents zope/plone. He gives it a winning fun factor score for hello world... by doing through-the-web development. So he says Zope [2] rocks precisely because of features that many of us have been largely ignoring and advising against for a couple years now. The kind of thing that the built-in zope 2 tutorial shows you how to do. Why is Zope 2 TTW fun? - No restarts - No configuration That's certainly food for thought. The sample app demos were also interesting... he kinda glosses over what exactly was the full zope/plone stack and how he did it, but since he generated a Plone content-like app from a UML model it's not hard to guess :) Notably it was the kind of app that sits squarely in the single-developer- in-a-hurry space. The I just want some forms to save some data and I don't want to care how it works space. The space where, as Jim keeps saying, zope 2 traditionally excelled and Plone lives today. A similar app could've been written pretty quickly in Zope 3 by writing a schema and using browser:addform, browser:editform, and browser:schemadisplay. It would be interesting to see how that would go in the movie. I suspect that the movie author (named Sean Kelly i think?) would've complained about the xml sit-ups and the numerous server restarts. (In the middle of the movie he gives a link to his article at http://www.developer.com/xml/article.php/3583081 which includes the line The fad of applications using XML for their configuration files is dismaying, to say the least...) This is the kind of guy for whom TTW development really is compelling. Watching the hello world section reminded me of when I used to really enjoy doing that stuff. But there are some important things left out of that story. Why did I stop enjoying TTW work? Like a lot of Zope 2 developers: * I needed my work to live in CVS. ZODB history and undo isn't good enough as version control. * I needed to write tests that I can run without having a real ZODB and without starting up a server. * I needed a sane way to deploy software from dev to staging and from staging to production. ZSyncer is fine for what it does, but it too is a poor substitute for version control, shell scripts, make, et al. * The unix shell still beats the pants off the ZMI as a complete working environment (even with ExternalEditor, the find tab, etc.) * I got tired of bouncing between restricted and unrestricted code. I want to live in unrestricted code as much as possible. Ultimately the zope 2 restart time started to become less of a problem than dealing with all those problems when working TTW. For CMF development, I settled on a pretty nice compromise: templates and scripts in filesystem directory views, with the scripts doing only view-related glue. This got me files on the filesystem and in CVS, and no restarts when tweaking UI. The scripts are easily testable using CMFTestCase. Pretty nice way to work. I still have to deal with some restricted code, but I'm mostly resigned to that. In Zope 3, we take restarts and filesystem-only development for granted, because it's intended specifically for the audience that I'm a member of... developers who have those concerns. I'm hoping to see a similarly interactive, yet long-term-sane, working style evolve for in zope 3. Maybe we'll get there with Persisent Modules and fssync. If there's a moral to this story, it's this: Scaffolding that gets you up and running with a minimum of fuss is a great thing. Rapid interactive and iterative development is also a great thing. But if you can't easily transition from there to more complex apps that are still maintainable, it sucks. It's irritating to have to throw away some of your knowledge and completely replace it with new ways of thinking; it's better if the new knowledge strictly supplements the old. It's worse than irritating to have to throw away your work and rebuild it from scratch; it's better if your new work can cleanly leverage the old. Put another way, if we consider Jim's first two audiences, how do we teach a single person to move from i don't want to have to care to zope zen master / SVN contributor with minimal wasted effort along the way? Today I don't know if there's a clear coherent story to be told there, even for zope 2. If there was... wow, that would be a great. Sorry if I haven't really said anything new. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
On Mon, Mar 06, 2006 at 05:13:57PM -0700, Jeff Shell wrote: On 3/6/06, Paul Winkler [EMAIL PROTECTED] wrote: A similar app could've been written pretty quickly in Zope 3 by writing a schema and using browser:addform, browser:editform, and browser:schemadisplay. It would be interesting to see how that would go in the movie. I suspect that the movie author (named Sean Kelly i think?) would've complained about the xml sit-ups and the numerous server restarts. Those are bad options anyways. They do not have growth potential either, as you then have to make the conceptual leap from something magically generated by this XML declaration into how do I customize what happens on edit? Actually I agree with you. Dynamic scaffolding has the same problems I was complaining about re. TTW development: it does a bunch of magic that you have to understand and know how to do from scratch the moment you want to go beyond it. In that paragraph I was only trying to fit zope 3 into the kinds of things done in that movie; some of his other examples are pretty magical too. I write this UML model and presto, I get all this with zero lines of code, wow neat. What I'd really like is something like what you say later on: This is an area where Rails is particularly strong. I'm normally not a fan of code generation. But their tool generates just-enough. It's code you can actually understand and start building from, and a quick run to the api docs they have online is usually all that's needed to start understanding the code you're looking at. The code their tool generates runs basically what you see if you have it dynamically providing 'scaffolding', so the conceptual difference between the automatically generated and what it gives you out of the box is pretty small. OK, so what if we had a code generator that would read some browser:addform/editform/schemadisplay directives and spit out some functionally equivalent code (python, zcml, and zpt) that you could just start using and editing? I think that might be pretty handy. I really like the concept of through the web tweaking and manipulation. But I'm sick of templates and scripts. I'm not quite sick of templates yet, but I am sick of scripts. I still use them in CMF because they give me a convenient place to do what I described: view-related glue that I can tweak without restart. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Notice: zope.interface is now a separate project
At pycon we have just moved zope.interface into a separate project (in preparation for eggification). It's now a separate project at http://svn.zope.org/zope.interface/trunk/ and is stitched into zope as an external. To update existing trunk sandboxes, you'll want to make clean before doing svn up. If you have local changes under zope/interface, those will prevent an update. We are planning to do this to a number of other packages: zope.i18n zope.i18nmessageid zope.deprecation zope.exceptions zope.tal zope.component We'll give more status updates as we make progress on these. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Re: Two visions
On Tue, Feb 28, 2006 at 12:31:33AM +0100, Philipp von Weitershausen wrote: I will also note that just because Zope 2 won't die, it doesn't mean we shouldn't clean it up. Eventually, Zope should mostly be reusing things from Zed. +sys.maxint I think this will be the way we get a real forward migration path for an awful lot of us who are still using Zope 2 today, and expect to continue doing so. We may or may not ever port to zope 3, whatever that will mean in the future. More likely we will just incrementally improve and clean up our applications, just as Zope 2 itself will be getting incrementally better and cleaner. We'll have to address deprecation warnings at each upgrade, but at no point will we be forced to do a complete rewrite. And along the way, we'll be gradually getting access to more and more nifty features. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Notice: zope.testing and zope.deprecation are now separate packages
OK, we now have two more packages separated: http://svn.zope.org/zope.deprecation http://svn.zope.org/zope.testing As before, if you have existing trunk checkouts, you may need to make clean before you can successfully update. Local changes in those packages will also block updates. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Notice: zope.testing and zope.deprecation are now separate packages
FYI, this is the cause of some intermittent buildbot test failure messages while we move stuff around. We're keeping an eye on these. Currently looks OK. On Mon, Feb 27, 2006 at 06:56:38PM -0600, Paul Winkler wrote: OK, we now have two more packages separated: http://svn.zope.org/zope.deprecation http://svn.zope.org/zope.testing As before, if you have existing trunk checkouts, you may need to make clean before you can successfully update. Local changes in those packages will also block updates. -- Paul Winkler http://www.slinkp.com -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Notice: zope.i18nmessageid is now a separate package
Yet another package is now separated: http://svn.zope.org/zope.i18nmessageid As before, if you have existing trunk checkouts, you may need to make clean before you can successfully update. Local changes in this packages will also block updates. btw, these packages do not currently install properly into site-packages if you do setup.py install. That's because we have not (yet) properly handled namespace packages as described at http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages ... we are holding off on that until we play with eggs some more. We're done for today, more tomorrow. -- Paul Winkler http://www.slinkp.com ___ 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: Zope 3 web root
On Fri, Feb 17, 2006 at 10:14:50PM -0600, whit wrote: Paul Winkler wrote: +1. The killer moment for me with ZClasses was when I realized I wanted to convert one to a filesytem Product and that meant I had to literally throw away everything and start from scratch. Never again. now, if you could export all the behavior to sane fs code, would that moment still have been a killer? or would suddenly TTW just be another part of the toolchain? Yes. That would've been great. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Brainstorming about browser pages
On Fri, Feb 17, 2006 at 10:21:41AM -0800, ksmith99 wrote: I think the template should be considered auxillary, not the view class. That's how I've been thinking lately. The view class is_a view and uses_a template. ZPT isn't the only template option. As Z3 opens up, developers are going to demand more templating choices like Kid, Cheetah, Meld3, etc... ... clearsilver, stringtemplate, lxml.etree.XSLT... -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: merge zope-dev and zope3-dev?
if we're voting, I'm +0. -- Paul Winkler http://www.slinkp.com ___ 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 3 web root
On Thu, Feb 16, 2006 at 02:16:05AM -0700, Jeff Shell wrote: I think that Zope 2 suffered heavily from the too many ways to do it when it came to ways of doing development, and there were gulfs between each style. Each style had its plusses too. ZClasses certainly had an appreciative audience who liked defining schemas and building forms automatically through the web with little programming required. But working with templates and scripts in ZClasses had a bit of a different feel and behavior than working with those things in the 'content' space of the site. And it was very different than working with file system based products. +1. The killer moment for me with ZClasses was when I realized I wanted to convert one to a filesytem Product and that meant I had to literally throw away everything and start from scratch. Never again. That's also what I dislike about zope 2's scripts. What the hell are they? Script is a misnomer, they're more like function bodies with access to a magic set of globals (context, container, and so forth). If you want to convert a script into a method of a zope 2 Product, you have to figure out what those bindings would mean in the context of that product, maybe even change the call signature and update all the callers. This is tiresome. I liked the Persistent Module proposal better, in theory, although I'm not sure how much I would have liked it in practice given some of the restrictions that were proposed. So my plea is: If we're going to have more than one way to do it, let's please not invent lots of special magical things that just work in one mode of development and have to be laboriously rewritten in the other mode of development. It makes the border between modes of working too hard to cross and makes Zope 2 feel rather un-agile at times. environment. It's less natural for Python. If persistent code doesn't behave quite like regular Python code, then there's still a gulf that has to be crossed when one wants to move up from persistent code. Right. That gulf should be very very minimal, or special kinds of code (whether persistent, or somewhere in Shane's filesystem tree) eventually becomes a pain IMO. OT subject=zope2 Lately I've been wondering whether the whole security-restricted feature of Zope 2 TTW scripts is even a feature at all. I've always toed the party line that it's a good thing that joe shmoe scripter can't shoot himself in the foot by creating a regular expression that crashes the server. But then, I've never met joe shmoe scripter. I think zope.org's model of allowing barely-trusted people to develop software on a public site through the web is rather exceptional and dubious as the basis for framework development. Everybody writing scripts on all the projects I've done has been a full developer with full filesystem access; our scripts generally lived in CMF FilesystemDirectoryViews; the whole restricted thing was nothing to us but a giant PITA. Then I got to wondering: Are there any other web frameworks that have restricted code? As far as I know (which isn't very far), J2EE doesn't, Rails doesn't, DJango doesn't, Subway doesn't, and *none of them envy us for it*. Maybe they are right not to? I know that if a user writing a script could import and call anything, he could elevate his permissions and get access to previously-denied parts of the system. What I'm finding increasingly dubious is the idea that a person who's not allowed access to the whole zodb should be allowed to write code at all. /OT -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On Thu, Feb 16, 2006 at 01:19:38AM -0700, Jeff Shell wrote: Am I the only person who uses apidoc to look up what can be done with ZCML? I dunno if it's just me, but http://localhost:8080/++apidoc++ is 404 on a fresh 3.2 instance. Aside from that, I noticed that the help popup in the ZMI contained a link to http://dev.zope.org/Zope3/FAQ which redirects to http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FAQ which was really really horribly out of date. I just very quickly updated a bunch of things, some of them are still probably wrong, I didn't look at everything. It's still in need of attention from some more knowledgable folks... even five minutes could make a difference. -PW -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On Thu, Feb 16, 2006 at 12:31:46PM -0500, Paul Winkler wrote: On Thu, Feb 16, 2006 at 01:19:38AM -0700, Jeff Shell wrote: Am I the only person who uses apidoc to look up what can be done with ZCML? I dunno if it's just me, but http://localhost:8080/++apidoc++ is 404 on a fresh 3.2 instance. It was just me, cancel that :-) -- Paul Winkler http://www.slinkp.com ___ 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: Re: tal:define=... considered harmful?
On Thu, Feb 16, 2006 at 07:06:03PM +0100, Jean-Marc Orliaguet wrote: Yes, that's what I mean. Clearsilver is a good example. There are several advantages: - the data structures are platform-independent (they can be encoded in JSON, C, python), and they can be easily converted from one language to another, even to and from XML, this simplifies the transport too (e.g. in Ajax, webservices) - the template does less, it does not need to know anything about zope, it works faster, the data access from inside the template is not an access to the ZODB ... - it is possible to create a simple schema definition from the data structure itself (this is what I've done in the Ajax toolkit I'm writing) Another advantage: - the template itself is truly platform-independent ... which is attractive in mixed-platform environments. The StringTemplate guy has an interesting take on templating and model/view separation: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf Particularly the stuff about the five rules implied by strict model-view separation. -- Paul Winkler http://www.slinkp.com ___ 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: Re: tal:define=... considered harmful?
On Thu, Feb 16, 2006 at 08:05:56PM +0100, Jean-Marc Orliaguet wrote: I think that the principles stated in that article, of clean separation between model and view (called encapsulation) are more important than the template's actual syntax. But the syntax is important too since it's humans who write templates .. Agreed. I like the TAL approach to syntax best, at least for XML-ish jobs. What's also missing is speed, which eventually matters. StringTemplate, at least the Python implementation, is dog slow compared to ZPT. ClearSilver, on the other hand, can be much much faster than ZPT. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Last chance to comment on Simplify skinning
On Fri, Feb 17, 2006 at 01:17:22AM +0100, Philipp von Weitershausen wrote: Either way, resource definitions are not quite the goal of my proposal so I'll leave it out of there. Perhaps Paul or whoever has the need for it would like to implement a resourcesFromDirectory directive... I'll see if I can get to this during the pycon sprint :) -- Paul Winkler http://www.slinkp.com ___ 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: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 03:39:02PM +0100, Philipp von Weitershausen wrote: Maybe I mean something different. I just want a folder in which I can drop all the files I want to customize (I love to customize), without registering something. That's not how it works in Zope 3, at least not right now and not by default. My proposal doesn't isn't addressing this. Shane has expressed an interesting idea that goes into the I just drop my stuff in here direction, but I'm frankly missing some important points in this idea yet. It might be interesting to develop it further, though. For now, however, we have to explicitly register everything. I consider that a good thing. I think it's an important use case, though. In CMF, annoying and limited as it was, installing a skin was a one-time job. Adding or removing resources in that skin was trivial. I think you don't care for the wrong reasons. You want your CMF experience duplicated. Perhaps you're not as bothered as I was with the CMF's limitations, but it sured annoyed me as hell having to create a new layer for every product I wrote for CMF. Yes, I didn't like that either. Neither do I like the current system. I have to explicitly register every one of my skin's 35 resources? This is a significant burden. I do that a lot more often than I create new products. I think what we're angling for is some way to register everything in a certain directory as resources with one directive. -- Paul Winkler http://www.slinkp.com ___ 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: Last chance to comment on Simplify skinning
On Wed, Feb 15, 2006 at 12:44:36PM -0500, Benji York wrote: Paul Winkler wrote: I have to explicitly register every one of my skin's 35 resources? If the 35 resources (files) are in the same directory you can use the resource directory ZCML directive. Or am I missing something? Only that I have the same question Martijn does: Can I then override one of those resources and keep the other 34? -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Indirection Reporter
On Mon, Feb 13, 2006 at 10:18:24AM -0700, Shane Hathaway wrote: I want a way to inspect all of the indirections chosen in the course of a web request or any other publishing operation. After executing a web request, Zope will report all of the points where it made a decision using the component architecture. It will show what decision it made and which ZCML directive caused it to make that choice. I haven't the foggiest idea how that would be implemented, but if you could make it work, wow that would be cool. Both as a learning tool and as an invaluable debugging aid. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Sum of Decimals
On Wed, Feb 08, 2006 at 11:08:57AM -0500, Stephan Richter wrote: Decimal is a new type and we have not yet declared it to be a rock. What is a rock? -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Selecting a code name
On Tue, Feb 07, 2006 at 09:42:31PM +1100, Rob Jeschofnik wrote: Paul Winkler wrote: Mac OSX in itself, on the other hand, was brilliant. With one letter they managed to establish: [...] Right... but that is a brand, not a codename. As I understand it, people are discussing things like Tiger, and Panther, to follow your example. Both codenames and brands are under discussion here. As I said before, I'm +0 on enhancing the brand, -1 on adding release codenames. IMO codenames make it harder, not easier, to talk about releases. Which came first - Cheetah or Puma? I submit that nobody but a certified mac geek can answer that question without googling it. -- Paul Winkler http://www.slinkp.com ___ 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: Selecting a code name
On Tue, Feb 07, 2006 at 03:09:01AM -0700, Jeff Shell wrote: and this, which I absolutely love: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html +1. I think we really need something like that. I know that even I would care a lot less about new Python releases if -- Paul Winkler http://www.slinkp.com ___ 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: xmlrpc:view (and jsonrpc:view)
On Sun, Jan 29, 2006 at 12:19:24PM +0100, Balazs Ree wrote: So this is where I see the importance of this: allow access to a method/template via RPC only, and disallow the method to be called directly from the browser. I'm curious. How do you distinguish between a jsonrpc request and a direct browser request? -- Paul Winkler http://www.slinkp.com ___ 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: Deploying WSGI Apps with Zope 3.2+
On Mon, Jan 30, 2006 at 09:36:12PM +, Chris Withers wrote: Tres Seaver wrote: +1 to that. I think Chris doesn't really believe in the Second Law of Python (according to the prophet Peters). Urm, can you refresh for someone with hazy knowledge of PSU epistles? [EMAIL PROTECTED] ~ $ python Python 2.4.2 (#1, Nov 3 2005, 23:58:28) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type help, copyright, credits or license for more information. import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. (snip) while ZCML uses its own style with minimal nesting, many attributes, and many namespaces. What? Insanity ;-) import this (snip) Flat is better than nested. (snip) Namespaces are one honking great idea -- let's do more of those! ;-) -- Paul Winkler http://www.slinkp.com ___ 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: ZCML bad ;-)
On Sun, Jan 22, 2006 at 10:58:43AM -0500, Jim Fulton wrote: Jeff Shell wrote: But I'm really starting to get frustrated with a lot of the elements in the ZCML browser: namespace. (snip) To a large extent, they were failed experiments. Just stop using them. Eek. How do those of us who are still neophytes recognize which browser: directives are failed experiments? Is there anything in the browser: namespace we *should* use? I count 18 in Philip's book which I just got. Menus are best understoood as a pattern! I'd like to see this somewhere in the z3 wiki on zope.org, but I don't see an obvious good place to put it. Somewhere under User Documentation? -- Paul Winkler http://www.slinkp.com ___ 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: ZConfig and other formats for ZCML
On Fri, Jan 20, 2006 at 07:58:52PM +0100, Dieter Maurer wrote: Paul Winkler wrote at 2006-1-20 10:26 -0500: ... Does this mean we could potentially change zconfig options at runtime? What do you mean by that? You can already now change zconfig options at runtime (you can modify the object returned by getConfiguration()). But usually, it will have little effect, because most configuration options are read just once -- during startup. For them, later modification will have no effect. Oh, OK. Thanks for clearing that up for me. -- Paul Winkler http://www.slinkp.com ___ 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: Make HTTP streaming of large data simpler
On Tue, Dec 20, 2005 at 10:48:24AM -0200, Sidnei da Silva wrote: On Tue, Dec 20, 2005 at 07:33:13AM -0500, Jim Fulton wrote: | I'd really like us to think about how we *want* this to work in Zope (2 and | 3). | | I'm uncomfortable with the subtle cues that seem to change the behavior of | request.write from non-streaming to streaming. Agreed. I had no idea about those cues until Sidnei pointed it out. | I'd like to see | a proposal for a clean API that supports: | | - Simple traditional output (ie pages) | | - Non-streaming large-file output. | | o Don't hold application thread to do I/O | | o Don't consume a lot of memory | - Streaming output | | o For applications that tale a lot of time to generate | output. | | o Output is generated over a long period of time. | | o Perhaps extends life of application thread. | | (Maybe there are other alternatives.) In zope 2 you can also do RESPONSE.setBody(foo), where foo provides ZPublisher.Iterators.IStreamIterator. Works well for what you're calling non-streaming large-file output. However, it doesn't handle the streaming output case: for two reasons: 1) there's a big Don't Do That note in the docstring about not using the database in your iterator code; 2) it mandates a precomputed content-length, which could be fixed pretty easily: http://www.zope.org/Collectors/Zope/1962 One thing that I had in mind for long-running streaming output is that 99% of the time it just needs a constant, read-only view of the database at the time the streaming started so instead of using a connection from the zodb connection pool, it could open a new, read-only connection and use that for delivering the content. I agree that read-only is the more likely scenario. However, the 1% may be more than 1%. Suppose I'm writing a UI for maintaining a gigantic site. Some actions might be inherently slow and inherently write to the ZODB - e.g. rebuilding a massive catalog. I like to give feedback to the user early and often, if possible. Another case that affects me today: using ZSyncer in pull mode. In current ZSyncer cvs, i use response.write() with http 1.1 chunking as Sidnei described, and it works nicely for giving feedback as each item is fetched or pushed. Some of these operations involve writes, and none of them have a known output size, so I can't currently use an IStreamIterator. -- Paul Winkler http://www.slinkp.com ___ 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: Twisted Publisher and Zope 2
On Thu, Dec 08, 2005 at 07:31:56PM +0100, Christian Theune wrote: - WSGI disallows response streams It what??? Seriously? That's a showstopper for a lot of projects. -- Paul Winkler http://www.slinkp.com ___ 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: Twisted Publisher and Zope 2
On Thu, Dec 08, 2005 at 02:05:55PM -0500, Jim Fulton wrote: Paul Winkler wrote: On Thu, Dec 08, 2005 at 07:31:56PM +0100, Christian Theune wrote: - WSGI disallows response streams It what??? Seriously? That's a showstopper for a lot of projects. Uh, what is the it/that that you are talking about? I have no idea what WSGI disallows response streams above means. WSGI is designed sprecifically to support streaming via Python iteraction. Yes, I see that now, and posted as much in parallel to your reply. Sorry for being alarmist. The major change is that the response 'write' method is no longer supported. If that causes breakage of existing Zope 3 apps, then we can add it back. It was our judgement that it wasn't being used, so we dropped it. I think this is only a problem if/when this stuff is used in Zope 2. There's an awful lot of zope 2 code using RESPONSE.write(). But of course you know that, so I'll shut up now. -- Paul Winkler http://www.slinkp.com ___ 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: Make HTTP streaming of large data simpler
On Tue, Dec 06, 2005 at 12:01:37PM -0200, Sidnei da Silva wrote: On Tue, Dec 06, 2005 at 08:55:56AM -0500, Jim Fulton wrote: | Interesting. I wasn't aware of this in Z2. Zope 3 definately | doesn't have this. Sindnei, have you verified that this actially | works in Z2? I didn't think the Zope 2 publisher actually started | propducing output until the request was finished. Yes, I can confirm it works like I described. I've been using and relying on this (where this == chunked response producing output before the request is finished) on Enfold Desktop for a while. But, as Sidnei pointed out to me offlist, it's not as modular as a first glance at the code would make one hope :-) From an offlist mesage: Actually, chunked_producer doesn't seem to be used, afaict. Chunking is inlined in the body of HTTPResponse.write(). That could really get some loving. I've recently added 'gzip' content-encoding to streamed content by hacking around the 'ChannelPipe' and it was a real pain to do gzip+chunked. Updating the compressed producer to add the missing zlib header + checksum and actually using those instead of hardcoding it all in ZServer would be very interesting. BUT, in the light of Zope 3 moving to twisted, and possibly Zope 2 at the time of Zope 2.11, maybe that's not worth the effort. -- Paul Winkler http://www.slinkp.com ___ 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: Make HTTP streaming of large data simpler
On Mon, Dec 05, 2005 at 11:13:31AM -0500, Jim Fulton wrote: BTW, your implementation also doesn't work because it doesn't set the content length. Speaking of which, I'd love to see a way to make this work for situations where you can't precompute a correct content length because e.g. you're building a lot of data on the fly but you still want to start streaming it as early as possible. In this case, the HTTP spec says that you should NOT set the content-length header but you must close the channel to signal end of data. Or at least that's what Dieter says it says :-) http://mail.zope.org/pipermail/zope/2005-November/162714.html Apparently, according to Dieter, Zope 2 doesn't let you use this idiom; does zope 3? (I've very briefly looked at the Zope 2 code in medusa, and I can't quite tell if Dieter is correct - there seems to be some support for the chunked transfer coding, which should do the job, but I'm not sure if/how one can currently take advantage of it.) -- Paul Winkler http://www.slinkp.com ___ 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: Make HTTP streaming of large data simpler
On Mon, Dec 05, 2005 at 04:31:03PM -0200, Sidnei da Silva wrote: There are a couple conditions that must be met for 'chunked' to work with Zope 2. Cool. Does Z3 behave the same way? 1. A Content-Length header must not be set. 2. The request must be HTTP 1.1 3. You must be streaming 4. No 'Connection: close' header has been set during the request Does be streaming mean something that isn't covered by the other requirements? ... hmmm, (reading more code), do you mean that RESPONSE._streaming must be true? Aha, I see that RESPONSE.write() implicitly sets that flag. If all of that is met, then it works just fine. The signal for 'end of data' in chunked mode is '0\r\n\r\n', which Zope properly inserts when appropriate. OK. Aha, I'm now looking at medusa/producers.py and I see that happens in chunked_producer. Thanks for the info. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository
On Thu, Nov 24, 2005 at 06:59:46PM +0100, Martijn Faassen wrote: Cool to hear you're giving Five related talks. Is there any description of these available online? (not that it's likely I'll be able to attend PyCon, but I'm very curious) http://wiki.python.org/moin/PyCon2006/Talks They're just basic How to develop with Zope and ...CMF talks, with as much Five as I can squeeze in since it's 2006 and it would be criminal to ignore it :-) I will not even remotely attempt to be comprehensive or deep. It will be very challenging to work in the short time slots alotted! I was a bit surprised that both talks were accepted, I figured I'd be trumped by presentations from better-known people, but maybe there weren't any! -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] fssync and export/import for Zope 3
Andreas Jung said: Export/import is likely much more important than being able to edit content on the filesystem. Writing simple mechanisms for exporting/importing schema-based content to XML/from XML should not be so hard. Yeah. And sometimes XML just gets in the way - namely, when you are dealing with blobs. The issue of human-readable exported data is orthogonal to the issue of backing up or transporting your data. Certainly worthwhile, but don't underestimate the value of plain old pickles. I don't know if anybody actually uses the XML option for exporting / importing Zope 2 data - I always use the default pickle format. It works fine and is more efficient. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
