Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
David Pratt wrote at 2007-10-8 00:21 -0300: Zope 2 is one application among many dependent upon zope 3. Zope 3 is different software than zope 2. I do not argue with you that Zope3 is different software than Zope 2. What I argue about is Zope 2 is an application. I have seen hundreds of applications built on top of Zope 2, long before someone thought about Zope 3. I interpret this as: Zope 2 is not an application but a web application framework. Recently some applications make not only use of Zope 2 but also of Zope 3 (prominent example is Plone 3). But Zope 2 itself is still only slightly dependent on Zope 3. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Stephan Richter wrote at 2007-10-6 13:40 -0400: ... I personally feel quiet offended to see Zope 3 degraded to a set of components. Zope 3 in itself is also an application server; Zope 2, on the other hand, is an application. Maybe, but then Zope 2 is an application with variants that are not recognizable as variants of the same application ;-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
David Pratt wrote at 2007-10-7 12:17 -0300: ... Zope 2 is a single application Are you sure you know Zope2 ? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Andreas Jung wrote at 2007-10-6 17:20 +0200: ... The distinction between Zope 2 and Zope 3 must disappear. We must speak of Zope. Everything else is counterproductive when it comes to promoting Zope. There is only one Zope developer community and most of us have a Zope 2 and a Zope 3 hat on (others have a CMF or a Plone head). An artificial separation between Zope 2 and Zope 3 developers is undesirable in my opinion. +1 -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
Gary Poster wrote at 2007-9-26 15:47 -0400: ... So, yes, you are right, I stated an extreme position and I could be argued away from the edge. But the extremity of my position is a simple, followable rule that I certainly prefer over the case you describe. Okay, we disagree. Non working releases produce problems for most people downloading them. Thus, if they are out, and no better release is available, get rid of them such that normal users would again get the earlier, better working releases. It may hurt special users (such as maybe you). Be it. -- 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: Known working sets II [was: Eggification redux]
Martijn Faassen wrote at 2007-9-26 22:13 +0200: ... I am the one who wants to have the final say in what versions of packages. I want to use. A linux distributor needs to have one working set of packages, instead. He may have one set of packages -- but he knows that not all of them work together. Moreover the set changes over time -- because new versions are released -- and finally the downloader is the one who has control over what he really installs on its local machine. Maybe, that's the equivalent to I am the one with the final say. ... We have a situation where we have developers, not maintainers, uploading new versions of packages. There will be no integrated testing done for all software built on all packages in the cheeseshop. Again, I can see similarities, but I don't believe linux distributions have *exactly* our problems solved. Our buildouts are used as development environments, not only deployment environments. Yes, we have less control over what is released on PyPI than a Linux distributor. But, you have control over what components your project depends on -- and you can select components based on underlying release care. Okay, you can also fix the dependency and thus skip careless releases... Sticking to stable versions helps, until a new stable version is released. Then all the old stuff suddenly starts using the *new* stable version, and probably break. You must have far worse experiences than I have. My components usually work across many releases with only very rare need to intervene (Five twice broke one of my products; I think that almost was it). -- 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: faulty releases and pypi access [update]
Jim Fulton wrote at 2007-9-26 18:14 -0400: ... We've just released 1.1. We guess the next release is 1.2. We change things and release, 1.2dev-r#. Someone fixes a bug and releases 1.1.1. Now there's a dev release of 1.2 that is actually older than the 1.1.1 release but that setuptools considers to be newer. I think this is fairly problematic. Then again, I think that dev releases are problematic in a lot of ways. In your example, it is likely, that the fix will also go into the 1.2 development branch. I.e. you will get an 1.2dev-r! with ! #. -- 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] Why do we restrict our egg testing?
Stephan Richter wrote at 2007-9-27 08:55 -0400: ... Roger is suggesting that we should have one, so that problems are detected early. Any comments on that? +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: Known working sets II [was: Eggification redux]
Martijn Faassen wrote at 2007-9-25 19:57 +0200: ... If you choose for flexibility first, people will need to think about versions all the time. I follow Tres argumentation: somehow the Linux distributors have this problem mostly solved: Standard distributions come with a set of known working components and quite weak dependancy declarations. When I install additional components, I will be told about potential conflicts (based on the weak dependancies) and asked what to do (install nevertheless, upgrade more things to get dependancies right or abort). Usually, I do not have to worry about versions -- only occationally (when I see conflict lists) or even more rarely, when something breaks even though there has not been a conflict. We currently made bad experiences with weak dependancies. I see several reasons for this: * not yet ready distributions (insufficiently tested, alpha quality) have been uploaded to PyPI We are now aware that we must not do things like this * installation tools have prefered newer versions over older ones, even when the newer versions were development/alpha while the older ones have been stable The tools meanwhile have changed and stick preferably to stable versions * The installation tools work incrementally with dependancies rather than based on a global dependancy graph. This is not yet changed. Maybe, our bad experience are drastically reduced when the above reasons are taken care of -- even with weak dependancies? -- 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] AW: Proposal, free views
Philipp von Weitershausen wrote at 2007-9-25 18:49 +0200: ... I think we should just not raise any deprecation warnings at all. Just the imports for BBB and be done with it. I like this very much :-) -- 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: Automated egg releases
Philipp von Weitershausen wrote at 2007-9-26 16:19 +0200: ... * That you should never ever delete a release, even if it's a brown bag release. But, if you know it is severely broken and you do not have a working replacement, you should remove it as soon as possible -- to avoid more people to get this broken state and allow them to usually get the previous working state instead. Mayby PyPI has a different solution to this then deleting the release? -- 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: reasonable syntax for multi-adaptation
Jim Fulton wrote at 2007-9-26 11:29 -0400: ... IFoo(x) IBar(multi=(x,y)) Actually, that is not the case. If x already provides IFoo, then in the first case, the existing object is retuned. Nothing is instantiated. OTOH, in: getMultiAdapter([x], IFoo) or getAdapter(x, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. Is this not an irrelevant implementation detail? Should I not concentrate on: I get an object related to x implementing IFoo? -- 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] faulty releases and pypi access
Stephan Richter wrote at 2007-9-26 09:12 -0400: ... I totally disagree. If we trust people with repository access, then we have to trust them with release making. If you subscribe to the egg process, you have to do frequent releases. Maybe, if you fix dependancies to single versions ;-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: PLEASE don't remove eggs [was Re: [Zope3-dev] faulty releases and pypi access [update]]
Gary Poster wrote at 2007-9-26 09:39 -0400: ... - Remove the broken files. I'm not sure if this is related, but I noticed yesterday at least of couple of eggs that we are using had been removed, in this case from zope.org. Please, whoever is doing this, stop. If a release is brown-bagged as far as you are concerned for some reason, please do not assume it is ok to delete for others. I do not agree. When I have understood Christian correctly, then these distributions were not working at all (they lacked ZCML files). Distributions not working at all should be deleted as soon as one recognizes they are not working at all -- to limit the damage they may cause. Of course, not having a tag in the SVN repository is not a sufficient reason to remove otherwise fully working distributions again. -- 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: reasonable syntax for multi-adaptation
Jim Fulton wrote at 2007-9-26 15:10 -0400: ... Jim Fulton wrote at 2007-9-26 11:29 -0400: ... IFoo(x) IBar(multi=(x,y)) Actually, that is not the case. If x already provides IFoo, then in the first case, the existing object is retuned. Nothing is instantiated. OTOH, in: getMultiAdapter([x], IFoo) or getAdapter(x, IFoo) either there is an error or some factory will be called. x won't be returned unless the factory happens to return it. Is this not an irrelevant implementation detail? No, the specified behavior is different. Hm. But getAdapter and getMultiAdapter may return x as well (when the factory decides to do this). Thus, why is it relevant? -- 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: Known working sets II [was: Eggification redux]
Martijn Faassen wrote at 2007-9-25 17:22 +0200: ... Should we then encourage everyone to hardcode version numbers in their setup.py's dependencies list? I think this goes against building applications from components -- as it drastically increases the probability of conflicts. Components should are week dependancy requirements to be maximally usable -- not fixed dependancies. I think, this holds for frameworks, too, as they are also components. -- 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: skin support for xmlrpc
Christian Zagrodnick wrote at 2007-9-18 08:35 +0200: On 2007-09-16 09:03:47 +0200, Dieter Maurer [EMAIL PROTECTED] said: Ok, then I suggest: * Provide an IRequestType interface in zope.publisher Does this name sound wrong? It suggests the the interface has to do with request types, maybe browser, xmlrpc, ... It that what we want? IAPIType? IApi? IHTTPApiType? /me is confused again. :/ Me, too. Terms are very important for me -- and I could not understand RequestType. What should it mean that zope.publisher provides an IRequestType. What types are these? Do you mean types in the sense of browser requests, xml-rpc requests, ftp requests, ... or something else? -- 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: skin support for xmlrpc
Christian Zagrodnick wrote at 2007-9-15 12:34 +0200: ... Ok, then I suggest: * Provide an IRequestType interface in zope.publisher Does this name sound wrong? It suggests the the interface has to do with request types, maybe browser, xmlrpc, ... It that what we want? -- 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: RFC: Known working sets
Chris Withers wrote at 2007-9-4 09:15 +0100: Philipp von Weitershausen wrote: As far as I understand your use case, i twould already be covered by my original proposal: you always have the option to locally override what's specified in the working set. I think Dieter may have meant something like: [grok-0.11] grok = 0.11 ZODB = 3.8.0-3.8.4 zope.component = 3.4.0,3.5.1,3.5.2 I think this orthogonal description may not be strict enough -- as the testing effort grows exponentially. Usually, you have tested a few sets, say a single one grok 0.11, ZODB 2.8.9, zope.component = 2.4.0 Now, I must integrate grok 0.11 with a component that requires ZODB 2.9.0 and zope.component 2.5.2. I run the tests and can then say: grok 0.11 works also with ZODB 2.9.0 and zope.component 2.5.2. But I do not know (without explicit testing) that grok 0.11, ZODB 2.8.9, zope.component 2.5.2 is a working set as well. Thus, the knowledge based on the two tests cannot be expressed by grok = 0.11 ZODB = 2.8.9, 2.9.0 zope.component = 2.4.0, 2.5.2 -- 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: What does python 3000 mean for zope?
Fred Drake wrote at 2007-9-1 03:14 -0400: On 9/1/07, Christian Theune [EMAIL PROTECTED] wrote: I think the byte/text change is excellent. I like the clean separation of the two. What I don't like is the omission of an immutable bytes type. Where is the problem -- now that we have pypi? When you need an immutable bytes type, you implement one and publish it on pypi (for others to use it as well). -- 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] RFC: Guide for maintaining software in the Zope repository
Andreas Jung wrote at 2007-8-24 21:01 +0200: ... ACK on everything of that. But reading code comes before understanding code. And the visual impression of code has a strong impact on how we read code and on how we understand code. True, but do you really read code to satisfy an esthetical need? When I read code, I always need an understanding of this code -- usually because the code does not what I suppose it should do. I never read code just for pleasure. Reading effort is usually much smaller than the understanding effort. While many people in the Python community seem to prefer loose code, I can better read and understand dense code. I can also read and understand loose code and my total effort is not dominated by the reading part. Thus, I could e.g. analyse a postgres (locking) problem by understanding its source although the code was horribly loose because the other (much more essential) aspects have been excellent: like conceptial documentation, well chosen names, well documented source... While I do not tell others whether they should write loose or dense code, I refuse to follow their preferences in *my* code. You can specify rules for your repositories -- and I will obey them. If the rules go however significantly against my preferences, then this implies fewer contributions from my side. -- 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] RFC: Guide for maintaining software in the Zope repository
Philipp von Weitershausen wrote at 2007-8-24 20:24 +0200: ... I wonder how you can like this language with significant whitespaces and lots of underscore rules then :). In fact, I dislike Python's grouping by indentation (especially how it is implemented in the interactive interpreter) and a few other syntactical aspects (e.g. the need to explicitly specify the object parameter in a method definition). But other aspects are very nice and outweigh the syntactical nastiness. I do not see lots of underscore rules, maybe because I disregard PEP 8... For me, the Java style (getMainType) is easier readable than the one prefered in the Python runtime library (get_main_type). -- 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] RFC: Guide for maintaining software in the Zope repository
Andreas Jung wrote at 2007-8-24 19:35 +0200: ... Whitespace rules have a major impact on the readability of code. Readability is a major point when we talk of code quality. Readable code does not make code automatically but good code has to be readable. Lots of whitespace does not make the code more readable for all persons -- it does not for me, for example. Other rules are more important: * use speaking names * ensure that a unit (e.g. a function definition) can been seen in its whole * carefully document complex operations * combine a general overview with detailed source documentation. -- 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] Backward compatibility and major releases (series) update
Jim Fulton wrote at 2007-8-22 15:57 -0400: ... I eventually came to the conclusion that our original conclusion was sound, but that we should only introduce backward incompatibilities when the need is very dire, as it will cause lots of pain. Very good! -- 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: Removed zope.security 3.4b4
Benji York wrote at 2007-8-16 08:59 -0400: ... I also recommend projects nail their version requirements so that no matter what someone releases, they will be unaffected. This is how we run the projects I'm involved in, and it helps that we can decide, on occasion, to pay off our version debt all at once, and not have someone else create emergency work for us. We discussed this some time ago. Precisely fixing the dependancies is a good thing for final applications. It is bad for components or in situations where the given application is composed from many mini-applications. -- 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] RFC: zopeproject
Philipp von Weitershausen wrote at 2007-7-18 22:59 +0200: On 18 Jul 2007, at 21:13 , Dieter Maurer wrote: ... I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. Right. This is what Martijn Faassen aptly calls the Zope 2000 development model. And it's probably about the farthest away from working together with other Python web frameworks I agree with this. and toning down Zope for an easier entry. But, Zope is quite easy on entry. I expect that the traditional Zope-the-application was easier to install and to build applications with than your new approach which requires: * paste * WSGI * zopeproject * the application package * one instance per application True, experts can combine different Python web frameworks -- but what part of the Zope audience will need this? True, Python experts can be more economic with their knowledge. But, it appears the things become more difficult for non-experts. -- 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] Dealing with external dependencies
Philipp von Weitershausen wrote at 2007-7-18 23:24 +0200: Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Which often is not so bad. Many of my modules have been developped for ancient Zope versions and kept running for several Zope releases -- even major ones. Thus, unless I do not know whether a given package will *not* work will a given future version of a dependancy, I will not want to state the dependancy for the current version -- as chances are high that it will indeed work with the next few future versions. ... Things are a bit different with external dependencies (docutils, mechanize, ClientForm, twisted, etc.), I think. They bear a higher risk of breaking stuff for us in future releases, even if they're just minor releases, because we don't control them and their developers probably don't test their stuff with our code [1]. Back in the old days, we would do vendor imports or use revision tags for the externals. This was basically the equivalent of depending on a specific, well-known working version of the external package. I propose to do the same for the external dependencies we have. So far I only count docutils as an actual egg dependency because mechanize, ClientForm and twisted are still packaged up in the egg that uses them (we should change that, too). I will therefore change zope.app.renderer to depend on docutils==0.4, unless there are objections. Don't you drastically increase the risk of conflicts? As I understood in a different thread, you want to mix Zope eggs with other eggs from the complete Python community. Such eggs may have a dependency on the same external package than Zope -- and fixing the precise version by Zope can easily lead to conflicts. Please keep dependency requirements weak -- restrict only when you know it is necessary... -- 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] RFC: zopeproject
Philipp von Weitershausen wrote at 2007-7-18 01:13 +0200: ... Imagine you're writing a GUI application. Without question you'd use some sort of GUI toolkit (e.g. wxPython). Would you expect you would have to hook into the the wxPython application as a plug-in? Isn't it more natural that you simply write your application and just use the wxPython *library* wherever necessary? Is this not the difference between a framework and a library? An application uses a framework by hooking its components into the framework. A library is used directly -- only miminal hooking and callbacks are used. I view GUI frameworks typically as plugging my application parts into the GUI (which triggers my application code) -- especially, if the UI is build by an UI-builder... ... Zope 3 has now been successfully split up into separate pieces: individual libraries. I'd therefore like to propose an alternate approach to developing web applications with Zope: the library one, rather than the pluggable app one. I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. -- 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] How to debug zope3 if it completely hangs?
Fabio Tranchitella wrote at 2007-7-12 15:46 +0200:
...
I tried the suggestions from Benji, but using gdb and the commands from
debug-spining-zope results in a segfault of the zope3 instance I'm
debugging.
You could try the following gdb commands:
def ps
x/s ({PyStringObject}$arg0)-ob_sval
end
def pfr
ps f-f_code-co_filename
ps f-f_code-co_name
#p f-f_lineno
lineno
end
define lineno
set $__co = f-f_code
set $__lasti = f-f_lasti
set $__sz = ((PyStringObject *)$__co-co_lnotab)-ob_size/2
set $__p = (unsigned char *)((PyStringObject *)$__co-co_lnotab)-ob_sval
set $__li = $__co-co_firstlineno
set $__ad = 0
while ($__sz-1 = 0)
set $__sz = $__sz - 1
set $__ad = $__ad + *$__p
set $__p = $__p + 1
if ($__ad $__lasti)
# break -- interpreted as breakpoint
set $__sz = -1
end
if ($__sz = 0)
set $__li = $__li + *$__p
set $__p = $__p + 1
end
end
printf %d\n, $__li
end
pfr (Print FRame) can be used in PyEvalFrame (C level) call frames
to determine which Python code belongs to the respective call frame.
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [OT] mailman problem
Off-Topic (sorry) I would like to participate again in the dicussions. This is currently prevented by a mailman bug. The mailman process needs a restart. The long standing mailman bug causes digest delivery to stop. It affects the complete mail.zope.org (all mailing lists together) about every few months. A mailman restart fixes the problem temporarily. Maybe a newer mailman version has the bug fixed? Hope someone is able to restart mailman on mail.zope.org. -- 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: How to deal with major versions? (was Re: Re: egg version numbers and zope releases)
Philipp von Weitershausen wrote at 2007-5-31 21:35 +0200: ... I would prefer to spell Jim's example as: 1.=2.3 -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: A thought on backward compatibility and minimum versions
Philipp von Weitershausen wrote at 2007-5-31 22:04 +0200: ... How about foo 2.=5 This seems really weird to me. I much prefer: foo 2, =2.5 Would you be able to write foo 2.4, =2.4.3 Yup. Hmm, ok, then I'm at least not against it. But I still think my variant is shorter and more self-explanatory. It, definitely, is shorter -- but I cannot see why it should be self-explanatory. It severely bends the usual meaning of =: I associate it strongly with a binary operator -- and 2.=5 goes strongly against this association. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: How to deal with major versions? (was Re: [Zope3-dev] Re: egg version numbers and zope releases)
Jim Fulton wrote at 2007-5-30 15:30 -0400: ... IMO, having every dependency look like: project_name =X.y.z X.999 Is too cumbersome. Maybe, we should put this into perspective: What part of our time do we spend on the specification of dependancies? 0.01 per cent? Furthermore, a new major version probably introduces some backward incompatibilities. However that does not mean that a given component will not work with the new major version. In fact, I rarely have to change my components to support new major versions. Thus, it may not be that often we have to specify X.. -- 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] A thought on backward compatibility and minimum versions
Jim Fulton wrote at 2007-5-31 10:12 -0400: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: - Suppose that we always had access to the latest released version, - Suppose that, within a major release, all releases were backward compatible, Then I assert that there is no *need* to specify a minimum release within a major release. I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. -- 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] A thought on backward compatibility and minimum versions
Jim Fulton wrote at 2007-5-31 14:15 -0400: ... I fear my colleagues responsible to maintain the productive versions would not be happy: They want the system to be as stable as possible. If they need to introduce a new component, they usually prefer to just add this one component. Only if this forces other updates, they reluctantly will make them. The motivation for this behaviour: even if a newer version is supposed to be backward compatible, it often has slightly different behaviour which may trigger bugs in the other parts of a complex system. I agree, but this control should occur at at a different place. I suggest that when deploying or releasing an application or system, you want to fix all of the versions so that a released or deployed configuration is repeatable and so that changes are introduced in a controlled way. This can be done in a number of ways. You can have an application meta-package that specifies all of the versions, or, if you are using buildout, you can use buildout's facilities for fixing versions. For individual reusable library packages, you want to make the dependencies as non-restrictive as possible so as to maximize flexibility and reusability. I agree but not to specify a minimal version and instead to assume that always the latest release version must be used does not maximize but reduce reusablitity. Look at the following szenario: In a given system module A is installed in version M.m. For some reason, another module B in the system cannot work with A in any version M.m' with m' m. I know that this violates your assumption that any newer minor release is compatible with any older one (in the same major release). Unfortunately, such things happen Now assume we want to install module C which needs A in version M.*. If M.* implicitly means: the newest minor release in the M series, then C cannot be installed in the hypothetical system. If, on the other hand, the dependency is expressed by A =M.m, = M., then C can be installed. If your suppositions are only a form of introduction for the M.* syntax (or M*, if you prefer) but does not affect the semantics of M.*, i.e. if M.* means 'needs the module in *any* M version', then I have no objections. Even for me M.* is nicer than M.9. -- 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] System python for *development*? (Was: 3.3.0 tag broken by zc.catalog eggs?)
Marius Gedminas wrote at 2007-5-22 14:18 +0300: ... seem to be minor inconveniences rather than show-stoppers to me. I'd love to hear real horror stories. I do not have horror stories but dislike system pythons because they tend to have debugging symbols stripped. Unfortunately, Zope applications sometimes crash or spin and it is often very efficient to be able to use a C level debugger to analyse such situations. However, this has only any hope when Python still has its debugging information... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
Lennart Regebro wrote at 2007-3-28 18:25 +0200: On 3/27/07, Dieter Maurer [EMAIL PROTECTED] wrote: However, this approach is only efficient when the sort index size is small compared to the result size. Sure. But with incremental searching, the result size is always one, right? ;-) No. You want to have one (the best one) hit from a (potentially) large set of hits. The size of this set is essential whether or not a sort index is efficient. The principle is like this: Let S be the hit set. Assume you sort index consists of values i1 i2 and use D(i) for the set of documents indexed under i, Then D(i1) intersect S preceeds D(i2) intersects S preceeds D(i3) intersects S, etc in the result ordered by the index i. If the index size is small compared to S (and if we assume the hits are uniformly distributed over the indexed values), then each intersection can determine (on average) a significant amount of sorted hits. You can efficiently determine the first hits. Assume on the other hand that S contains a single element and that the index is large, then almost all intersections are a vaste of time (as the result is the empty set). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
Jim Washington wrote at 2007-3-27 08:24 -0400: ... If you see a sort order as one permutation of a list, the factoradic technique provides a key to that permutation. So, in theory, one would sort the list, and store the factoradic index for that permutation. The next time the particular sort order is requested, it's a simple matter of unpacking the factoradic. I have not done any tests to see whether unpacking a factoradic is significantly less expensive than re-sorting. Intuitively, it should be. In practice, I am not so sure. In what way is it different from caching? The packed factoradic seems like a cache to me. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
Lennart Regebro wrote at 2007-3-27 11:59 +0200: ... OK, at least this avoids the big intermediate results when searching over several indexes. But you still have to get all of the results, and sort them before you can return the X first. I have the impression that Lucene somehow solves this with their sorting indexes, but I'm not sure, and I haven't tried to understand the code. The ZCatalog, too, can use sorting indexes (and AdvancedQuery which stole the idea from ZCatalog). However, this approach is only efficient when the sort index size is small compared to the result size. If the result size is large, the sorting index can only help you to get the sorting values quite fast as they are stored compactly together. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
Jim Fulton wrote at 2007-3-26 15:55 -0400: ... On Mar 26, 2007, at 3:28 PM, Dieter Maurer wrote: Jim Fulton wrote at 2007-3-25 09:53 -0400: On Mar 25, 2007, at 3:01 AM, Adam Groszer wrote: MF I think one of the main limitations of the current catalog (and MF hurry.query) is efficient support for sorting and batching the query MF results. The Zope 3 catalog returns all matching results, which can then MF be sorted and batched. This will stop being scalable for large MF collections. A relational database is able to do this internally, and is MF potentially able to use optimizations there. What evidence to you have to support this assertion? We did some literature search on this a few years ago and found no special trick to avoid sorting costs. I know of 2 approaches to reducing sort cost: 1. Sort your results based on the primary key and therefore, pick your primary key to match your sort results. In terms of the Zope catalog framework, the primary keys are the document IDs, which are traditionally chosen randomly. You can pick your primary keys based on a desired sort order instead. A variation on this theme is to use multiple sets of document ids, storing multiple sets of ids in each index. Of course, this approach doesn't help with something like relevance ranks. 2. Use an N-best algorithm. If N is the size of the batch and M is the corpus size, then this is O(M*ln(N)) rather than O(M*ln(M)) which is a significant improvement if N M, but still quite expensive. The major costs in sorting are usually not the log(n) but the very high linear costs fetching the sort keys (although for huge n, we will reach the asymptotic limits). Right. The problem is the N not the log(N). :) Under normal conditions, a relational database can be far more efficient to fetch values either from index structures or the data records than Zope -- as * its data representation is much more compact * it often supports direct access * the server itself can access and process all data. With the ZODB, the data is hidden in pickles (less compact), there is no direct access (instead the complete pickle need to be decoded) The catalog sort index mechanism uses the un-index data structure in the sort index to get sort keys. This is a pretty compact data structure. The data usually is in IOBuckets which contain 45 values on the average. In a corresponding relational index structure, you could have several hundreds of values. and all operations are done in the client (rather than in the server). Which is often fine if the desired data are in the client cache. It avoids making the storage a bottleneck. Yes, but the if is important. Quite often, some operations flush almost all objects from the cache (partly because the cache is controlled by the number of objects and not by their size) and after that, filling the cache again takes ages. Moreover, a relational database can (and usually does) use caching as well. It is not restricted to a cliend side only technique. I know that most relational database backends have a different architecture than ZEO: use one process (or at least one thread) per connection such that several activities can interleave the high IO wait times. The one thread ZEO architecture must take more care not to become the bottleneck. -- 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: ZPT missing header
Christian Zagrodnick wrote at 2007-3-9 15:07 +0100: ... zope.pagetemplate.pagetemplatefile is removing the header. So it is the pagetemplate, yes. It did so for resources as well. But *only* for the plain HTML header, *not* an XHTML header. I don't see why they should behave different. While I agree that they should behave identical, I do not see a reason to remove the header. Why adding additional complexity, which may introduce bugs (as we have seen)? -- 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] Proposal for optimized Blob handling
Christian Theune wrote at 2007-3-7 17:37 +0100: I'm writing up a proposal for the ZODB to make even more efficient Blob handling possible. This includes not copying the data from an uploaded file, but using a `link` operation when possible. Is it possible at all? Uploaded files end up in a temporary file. They need to get moved away from this temporary location (as they are likely to be deleted at various administrator decided dates). -- 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] Proposal for optimized Blob handling
Christian Theune wrote at 2007-3-7 21:17 +0100: ... Nope. It won't disappear if you link it again. And the link(src, dst) does move it to a 'save' location ;) You do not tell us, which link you mean. Python's os.link creates a hard link which will only work if source and destination are on the same file system. It is not uncommon that temporary files are on their own filesystem. -- 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] Persistent declarations, dead interfaces and a TypeError
Sidnei da Silva wrote at 2007-2-23 12:08 -0300: ... Wonder if we can just check for that? And then how to avoid a dependency of zope.interface on OFS.Uninstalled.BrokenClass. You can positively check that the object is an Interface subclass. -- 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] python 2.5 optimizations and Zope Catalog ?
Christophe Combelles wrote at 2007-1-27 03:11 +0100: http://wiki.python.org/moin/NeedForSpeed/Successes while reading the highlights of python 2.5, I've found that some string and unicode operations, particularly **search** operations, are a LOT faster, sometimes 25x faster! As a result, (when z3 will work on py2.5), can we expect a great improvement in the Catalog? Unlikely, as the catalog's 'search' is very different from the string and unicode search operations. Phrase searches may however get a bit faster. -- 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: calling interface returns object, calling queryAdapter returns None?
Jim Fulton wrote at 2007-1-25 09:11 -0500: ... I disagree with this assertion for the reason that Marius stated, which is that adapters are factories and utilities are not. I Should I be really interested in this implementation detail? All I care of, is that the returned object implements the required interface and is related to the object to be adapted (if any). How the adapter is found/created is of no interest to me. -- 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: Zope 3 without ZODB
Philipp von Weitershausen wrote at 2007-1-22 13:51 +0100: ... I think the ZConfig argument was largely due to misunderstandings. I would be surprised if people really cared whether to Zope used ConfigParser or ZConfig (except Fred, perhaps ;)) And, as so often, me. -- 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: zope.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote at 2007-1-16 23:19 +0100: Dieter Maurer wrote: Martijn Faassen wrote at 2007-1-15 15:44 +0100: I would say refusing to guess and bailing out with an error message is better in this case. I disagree with you. Logically, parsing an encoded XML document consists of two passes: decode the encoded string into unicode and reconstruct the XML info elements from the serialization. Traditionally, these two passes are not performed one after the other but folded together in a single pass. But that tradition should not prevent to separate out the (Unicode) decoding phase. And after this phase is done, there is not ambiguity left with the XML declaration. Its encoding attribute is simply irrelevant for the second phase (apart from generating the PI info element). That's nice as far as it goes. What if after the second phase you need to parse the XML again? What do you do with your encoding header then? After the second phase, I now longer have an XML string but instead either a sequence of events (SAX style) or a tree of XML info elements (syntax tree style). But, whatever I have, the second stage does not magically change my unicode string. It could be parsed over and over again. If it's irrelevant, you better strip it out before you put it into the parser. I loose information then. The event stream or info element tree lacks the XML declaration PI then, or at least its encoding attribute. The parsing process is allowed to loose some information. For example it can loose whitespace details or the order of attributes. I don't know whether the loss or modification of PIs is considered acceptable. In general, this would definitely be wrong. I have read some article in comp.text.xml that complained about the loss of the encoding information -- at it may be a good hint about the default encoding to be used on encoding/serialization. This menas that some XML processing systems loose the information and not everyone is happy. -- 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: zope.tal.xmlparser.XMLParser() dislikes unicode
Andreas Jung wrote at 2007-1-17 17:48 +0100: ... So Martijn's and my proposal remain. They are not very different. In the end the behavior is almost identical. But I will adopt your suggestion to remove the preamble when storing the data internally (basically to avoid a possible encoding ambiguity). In future times, the preamble might contain information which should not be dropped, e.g. when there is an XML version different from 1.0. For PageTemplates, we know that the encoding information is probably not relevant after the parsing -- unless we want to use it as a default for the Content-Type charset but I doubt that this is a good thing. If the Content-Type's charset is given explicitely, then the encoding of the XML declaration needs to be adapted to this value during the serialization anyway -- thus overriding any encoding present there. -- 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: zope.tal.xmlparser.XMLParser() dislikes unicode
Chris Withers wrote at 2007-1-14 18:14 +: ... The problem comes when someone sends you something like: u'?xml version=1.0 encoding=something-else?node /' What should be done then? We parse the declaration and generate an info element for it but otherwise ignore it as it has lost its meaning after the XML has been converted to Unicode. -- 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: zope.tal.xmlparser.XMLParser() dislikes unicode
Martijn Faassen wrote at 2007-1-15 15:44 +0100: Hey, On 1/15/07, Andreas Jung [EMAIL PROTECTED] wrote: [snip] ok, got it. But this problem can be solved easily by changing the encoding within the preamble. I would say refusing to guess and bailing out with an error message is better in this case. I disagree with you. Logically, parsing an encoded XML document consists of two passes: decode the encoded string into unicode and reconstruct the XML info elements from the serialization. Traditionally, these two passes are not performed one after the other but folded together in a single pass. But that tradition should not prevent to separate out the (Unicode) decoding phase. And after this phase is done, there is not ambiguity left with the XML declaration. Its encoding attribute is simply irrelevant for the second phase (apart from generating the PI info element). Thus, there is no guessing; someone else has just performed the first phase of the complete process -- maybe using the encoding attribute or some overriding information. -- 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] Idea: Failure to lookup adapters
Sidnei da Silva wrote at 2007-1-15 17:25 -0200: ... The kind of info I'm looking for is something along the lines: 'We've tried to look up an adapter for (ISomething, ITheOther) but none was found' 'Found an adapter for IFoo, which is a base class for the IBar interface requested. No adapter has been found for the most-specific interface IBar' Comments? In Zope 2, I would use __traceback_info__ or (more likely) __traceback_supplement__ and the traceback formatting facilities in zExceptions.ExceptionFormatter. This is a very efficient way to analyse all problems that result in an exception -- far better than log entries. -- 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: zope.tal.xmlparser.XMLParser() dislikes unicode
Tres Seaver wrote at 2007-1-15 16:57 -0500: ... Frankly, I don't get the desire to *store* a complete XML document (as opposed to the extracted contents of attributes or nodes) as unicode My desire comes from the easy principle: all text should be unicode. Decoding/encoding happens only at the system boundaries and no longer internally. -- 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: zope.tal.xmlparser.XMLParser() dislikes unicode
Philipp von Weitershausen wrote at 2007-1-14 14:59 +0100: ... Traditionally, you parse an 8bit string, figure out its encoding (e.g. from ?xml encoding=utf-8? and return some representation of that XML with unicode data. That's why it's actually quite ok for XML parsers to only accept string data. Parsing usually means rebuilding the structure from a text string and *NOT* encoding guessing or Unicode decoding. Therefore, it is actually quite stupid for a parser to try to encode an already decoded string (i.e. a Unicode string) only that it can guess the encoding ;-) A halfway intelligent parser would accept Unicode when it gets it and concentrate on the remaining part of its task: either reporting structural events or building a parse tree. -- 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: Some ZPT insights needed
Martijn Faassen wrote at 2007-1-6 20:34 +0100: This kind of automagic unicode error defeating logic scares me. Andreas decided to switch to Unicode only page templates in a micro (!) release. As almost all Zope 2 applications return non-unicode strings (they almost had to as the page templates usually were non-unicode), he *MUST* provide some automatic unicode error defeating logic as otherwise most applications would break. I'd therefore like it if there were a way, application-root specific, to turn off any auto-conversion behavior. Do you think that would be possible? +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] Is there an alternative to zdaemon?
Jim Fulton wrote at 2006-12-22 15:55 -0500: Thoughts? We are using zdaemon widely and would be sad to loose it. The underdocumented argument is unjustified in my view: * zdaemon comes with reasonable online documentation (the help command) * like for all zconfig based programs, essential documentation can be found in the schema file. As the configuration options have been carefully documented (also quite common for zconfig based programs), this is sufficient documentation for the configuration. * There are other forms of documentation than testable documentation (aka doctests). -- 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: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Jim Fulton wrote at 2006-12-19 17:27 -0500: Dieter Maurer wrote: Jim Fulton wrote at 2006-12-19 11:54 -0500: ... I made a mistake several years ago when I decided to (have Amos) implement FTP over ZPublisher. The Zope publisher is a CGI-inspired HTTP-based and thus stateless API. It is a poor fit for FTP and I overgeneralized. Why do you think so? Because FTP is a stateful protocol and HTTP isn't. Yes, but with a minimal state... I implemented a ZServer based NNTP server over ZPublisher within a few days -- and did not have the feeling that I need to stress ZPublisher. I don't know anything about NNTP. It is as stateful as FTP, having a minimal state, too. ... Instead, I was pleased that I could use authentication, request logging, request profiling, transaction handling, error handling -- all features either in core ZPublisher or added by us. One could still use and benefit from many of the frameworks in Zope without using ZPublisher. We moved from a (papercut based) dedicated NNTP server implemented as a ZEO client (the type of solution, you currently seem to prefer) over to a ZServer based NNTP server on top of ZPublisher. And we were very pleased with the transition: both with respect to maintenance as with respect to performance Yes, we have to maintain a minimal state (for NNTP, this is, user identity, selected group and selected article) outside of ZPublisher and provide access to it via request and response. This is managed within a few dozens lines of code. -- 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: Need to get more involved in Web SIG (was Re: Fixing ZServer bugs?)
Chris Withers wrote at 2006-12-20 09:15 +: Martijn Faassen wrote: It would be very nice if we could make that work! Zope as a drop-in Apache extension would certainly help wider adoption. Yes indeed :-) We're not a normal pythonish Apache thing though, 'cos we need to rigidly limit the number of app server threads because of the zodb object cache. Someone already worked on this and reported success. He integrated a ZEO client via mod_python. -- 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] Fixing ZServer bugs?
Christian Theune wrote at 2006-12-19 10:06 +0100: ... Did we ever drop support for ZServer? The changelog reads 'replaced ZServer with twisted' which sounds very much like ZServer was defined obsolete. I have understood the discussions differently: As I understood ZServer should stay alongside twisted as it is much faster. -- 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] Core topic in Collector
Jim Fulton wrote at 2006-12-14 07:21 -0500: ... Yawn. IMO, the collect, despite it's flaws, isn't bad enough to spend time on, especially given other priorities. OTOH, I'd be happy to just switch to using Launchpad, which would require basically no effort, especially if we don't bother transferring old collector data. It is not a good indication for striving for quality when problem data is taken out of sight... Of course, not transferring old collector data is less work, but so is not writing tests or documentation ;-) -- 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: Usage of IAnnotations disrespects interface declaration
Christian Theune wrote at 2006-12-11 08:30 +0100: ... Both are not acceptable, especially option #1. We can't just change existing contracts as we see fit. Right. However, I think it's possible to regard this is a bug in the original contract. But, some adapters for IAnnotations may not know about the newly introduced responsibilities and fail to implement them. Thus, fixing this bug in the proposed way will introduce bugs at other places. -- 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] Java applets and zope3
Paul Carduner wrote at 2006-12-12 22:59 -0800: ... load: class http://www.carduner.net/Programs/Fractals/Attractor.class not found. java.lang.ClassNotFoundException: http:..www.carduner.net.Programs.Fractals.Attractor.class ... at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: open HTTP connection failed. Java tracebacks, too, are not so bad. As you can clearly see, the Java runtime tried to open an HTTP connection and failed. The reason is probably that it tried the wrong server. Use a TCP logger (e.g. EtherReal) to understand what the client does on the network level. -- 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: Can an adapter find out what name it was registered for?
Chris Withers wrote at 2006-11-28 18:09 +: Benji York wrote: Chris Withers wrote: I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... Because the same adapter can be registered more than once, it would actually need to find out all the names with which it was registered. Really? Now this is a use case I hadn't thought of.. can you give me some examples of where you've run into this? An example where an adapter *can* be registered several times was presented by yourself :-) The str adapter (factory) can be used to adapt anything to a string. You may register it several times because you may not want to adapt all interfaces with it but only those derived of several base interfaces. You may or may not use different names as you might have different types of string adaptation (e.g. different types of string presentations). The str example shows also that it is not sensible that the adapter registry framework gives the adapter (factory) a way to determine its name (str has nothing where the name could be sticked in). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] Heads up: bugs in zope.app.catalog?
Adam Groszer wrote at 2006-11-17 13:13 +0100: What is the `good` behaviour regarding None values? Do we need to catalog them or skip them? If you index them, you rely on a non garanteed implementation artefact: Python explicitly does not garanteed that comparisons between objects of different type are persistent across restarts. The BTree variants used in the implementation of indexes require that the keys are persistenty compared. Failing to do so, will break the index. The current Python implementation ensures persistent comparison results. Thus, you are on the good side. However, earlier Python implementations did not and maybe future implementations may not, too It is safer, to have just a single key type in your indexes... -- 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: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 21:11 +0100: ... Not sure what official terminology glossary you're basing this on I am basing this on the meaning of english words. An adapter is something that adapts (and not something that is adapted). adapt is a transitive verb. It applies to something. This means that an adapter, too, applies to something. It is a function. but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. I begin to understand where this comes from: In Chris' example, the adaption result is a string. It is very difficult to envision a string as an active object (what the name adapter suggests). In more complex situations the adaptation result is an active object that actively mediates between the interface it provides and the adapted object. This probably led to the use of the active term adapter rather than the more neutral term adaptation (maybe adaption). As Chris example demonstrates, it would have been better to call IZopeDublinCore(myobj) the IZopeDublinCore adaptation of myobj. -- 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: adapter registration question
Jean-Marc Orliaguet wrote at 2006-11-15 20:51 +0100: ... but what problem is all this supposed to solve? are you guys writing a PhD or something .-) ? Well chosen terminology is a key to understanding. Therefore, it is justified to discuss about it. -- 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: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). 'myStrAdapter' is the adapter factory. In my view, *this* is the adapter (adapting something to str) and not an adapter factory (as its result is a string object which does not adapt anything)... -- 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: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do That's the terminology abuse: '123' is not an adapter because it does not do the adaption. '123' is the *result* of adapting 123 to 'str'. You may call '123' the 'str' adaption of the integer 123. IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. With appropriate terminology use, you would call IZopeDublinCore the adapter and IZopeDublinCore(myobj) the ZopeDublinCore adaption (maybe adaptation) of myobj. Again IZopeDublinCore(myobj) is not an adapter but an adapted value. -- 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] adaptation based on class rather than interface
Martin Aspeli wrote at 2006-11-9 04:37 -0800: ... Why does your class not have a (non-marker) interface in the first place? The use of interfaces as documentation and as formalisms for expressing a class' functionality (in adapters, utilities etc) is one of the benefits that Zope 3 introduces. I can see how they may not always add that much value immediately, but they are a good way of ensuring things are reasonably well-defined, well-documented and easily locatable. I have quite a different point of view: Interfaces define essentially the signature of methods but these signatures can also directly be derived from the class. Zope3 interfaces are slightly better as they can also specify attributes -- which is very helpful as Python does not provide a good means for this. -- 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: Python version for Zope 3.4 ?
Philipp von Weitershausen wrote at 2006-9-28 11:22 +0200: ... The last time this was discussed with Jim, the idea was to try to use Zope 3's security proxy approach in Zope 2 for Python Script security - Jim and I had some ideas I need to dredge up from the back of my mind. I am quite fearful in this regard: Lots of existing code rely on the fact that trusted code can do anything without to worry about security. As security proxies restrict trusted code, too (though trusted code can remove the wrapper), we might get more security at the cost of massive backward incompatibility. -- 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: [z3-five] zcml questions
Chris Withers wrote at 2006-9-25 18:44 +0100: ... Can we have a papal edict that zcml that has side effects is a bug? (including the dotted name thing...) Hm: the purpose of zcml is to have side effects (register things, patch classes with marker interfaces, add permissions, ...) -- 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] Release management refinements
Philipp von Weitershausen wrote at 2006-9-13 11:05 +0200: Over the last couple of days we've been discussing Zope's new release cycle and the release management. I would like to sum up what seems to be the gist of those discussions: 9 month release period? --- I am almost convinced that we will make the same experience as the Plone people: when we strive for a 9 month release cycle, we will get a 12 month cycle... I think this is almost a law for software development: completing in time is the exception not the rule. -- 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: Zope 3.2 maintenance
Hanno Schlichting wrote at 2006-9-11 23:06 +0200: ... You got it backwards ;) I only forward-port any changes from older branches to the more recent ones, but never do any backports. The reason I do this is because before this, Plone developers tended to only fix a bug on the trunk or the latest stable release. My hope was that by lowering the bar by only requiring developers to fix a bug on the oldest maintained release branch, more people would actually do this and in fact I think this strategy has worked out. This works in conjunction with our quite well-maintained bug-tracker where bugs get assigned to the release they should be fixed in by a small group of people. A very good approach! Because all modifications done on released branch should be fixes only, we want almost all of them in the trunk as well. And there is a good chance that there will only be few merge conflicts. Unfortunately, I could not convince my colleagues to work this way -- despite a good practical experience. One argument has been: the Zope development does not use it... But two things to keep in mind that differentiate Plone from Zope3 in this regard are, that most of the fixes in Plone are template issues or minimal changes that apply cleanly on the newer branches and when they don't or I do not understand them I ask the bug fixer to forward port it. You can of course do this always. ... For Zope3 the only sensible option IMO is, as others already mentioned it, to have a fix-on-the-oldest-maintained-branch-first bug fixing policy which requires to forward port these fixes to all branches up to the trunk. Why are you that pessimistic about Zope3 -- once the moving around has stopped (which might be a challenge for automatic forward merging)? -- 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: Zope 3.2 maintenance
Hanno Schlichting wrote at 2006-9-11 23:18 +0200: ... Yes. We don't have a Hanno for Zope 3. And even if there would be someone willing to do this job, a good understanding of most of the internals would be a prerequisite, as merging something which you do not understand is indeed potentially extremely harmful. The number of people that have a deep understanding of most internals of Zope3 is fairly limited and I think their time is better spent on fixing the bugs in the first place. I am merging Zope modifications into our locally maintained Zope version since about 1998. Lots of merges took place without me even knowing that something happened and without any need to understand things. Of course, there have been occational problems and then I had to get local understanding to fix things. In the Zope3 forward porting case, we can instead ask the fix author to do the port instead. -- 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] Roadmap for Zope 3.4
Martijn Faassen wrote at 2006-9-12 11:25 +0200: ... On the one hand core developers seem to be happy to use the trunk for development projects, and on the other hand we demand a lot of work doing bugfixes in a release, up to the point where we delay the release itself. core developers probably have other means than simple Zope3 users. When you see some problems simple Zope2 users have, you may understand that they should not be bothered with bugs in addition... -- 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: [Zope-dev] Release schedule for Zope 2.11/3.4?
Martijn Faassen wrote at 2006-9-12 14:44 +0200: ... The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release. It's the nature of time-based releases, though. If nobody does anything in 6 months, does that mean we won't have a release at all? Of course! Why in hell should you make a release with nothing relevant in it? Both the release process are well as the upgrade process entail a considerable amount of work. You do it only if it is worth the effort. -- 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] Zope 3 as a reliable platform?!?
Stephan Richter wrote at 2006-9-5 08:36 -0400: On Tuesday 05 September 2006 08:26, Jim Fulton wrote: I think in the future, we should resist minor api tweaks just to improve spelling slightly. I disagree, if the API violates the style guide. If only after the API is in widespread use, a style guide violation has been noticed, then the violation cannot have been that severe. Otherwise, someone would have noticed it earlier. Often, style is a very personal matter. What some individuals feel as a violation may not worry other individuals. API changes should have the large part of the community in mind. -- 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] Zope 3 as a reliable platform?!?
Fred Drake wrote at 2006-9-5 10:50 -0400: ... Hmm. The Z3 style guide has never matched the Python style guide completely, and I think it would do more damage than good to change it. We adopted some things early on in Z3 development that I think helped, but changing it just because more is covered in the Python style guide seems arbitrary. When I remember right, then I read an important sentence in the Python style guide -- something along the lines: This is a guide: you should follow it but there are occasions when you may not do so with good reasons. That's what a guide is: a set of rules recommended to follow, not a lawbook to follow in all cases. -- 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] Zope 3 as a reliable platform?!?
Fred Drake wrote at 2006-9-5 15:03 -0400: On 9/5/06, Dieter Maurer [EMAIL PROTECTED] wrote: When I remember right, then I read an important sentence in the Python style guide -- something along the lines: This is a guide: you should follow it but there are occasions when you may not do so with good reasons. I don't know if this means you agree or not. I agree that we do not need to adopt the Python style guide for Zope3 development. I don't think this paragraph really applies to this discussion. Jim suggested that we change the Z3 style guide, and I'm suggesting that that's counter-productive. But, if some component (such as formlib) entered the Z3 core and it follows more the Python style guide then the Z3 style guide, then this would not mean we have to change this component's API (just to get it more in line with the Z3 style guide). I think this openess was what Jim suggested (and I agree with) -- 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: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these straight-forward APIs were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. I do not want to say that this is happening in Zope3 land. I do not yet use Zope3 in earnest and see what is happening more from the mailing list than from my own experience. So, for me, it would be great if developers would take more time to weigh up the what does this new feature or refactoring bring against the how much of a PITA is it going to be for everyone else to relearn this... I like new features but often could not see the gain of refactorings. Many refactorings in Zope 2 land were just silly, e.g. whitespace refactoring such as: from X.Y.Z import a, b, c refactored to from X.Y.Z import a from X.Y.Z import b from X.Y.Z import c I do see the gain of moving out general purpose functions from zope.app into zope. But, I would do it in a backward compatible way -- even when zope.app then contains quite a few trivial packages redirecting to the relocated packages. -- 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: Zope 3 as a reliable platform?!?
Tres Seaver wrote at 2006-9-2 13:03 -0400: ... I'm OK with having in-tree code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that janitorial deprecation is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the better name. The ongoing cost of that deprecation is then borne by everyone else. I have the feeling that almost the complete Python community is abusing deprecations. I was hit by deprecations in the email package: The deprecation told me to use a different method, but this method was not a full replacement for the old one and failed in my use case. In the next release, my old method was removed -- but fortunately, I know how to recreate methods and silence stupid deprecations. -- 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] z3c - be or not to be
Roger Ineichen wrote at 2006-8-25 18:27 +0200: ... The reason why; We really have no time to do this in the next couple of month. And the option sombody else doing it is also *NO* option because we have allready productive projects build on this libraries and have no time to migrate them for nothing. Yes renaming the z3c namspace whould technicaly possible, but for me(us) it's just a waist of time right now. Could be that I will change my mind in the future but not in the next couple of months. I have no opinion on namespaces (especially, whether or not z3c should be renamed). But technically, it would be extremely easy: If nothing else would change than the top level name, then a single module alias (e.g. sys.modules['z3c'] = zorg) would suffice to let all existing software work as before. -- 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: New beta releases tonight
Philipp von Weitershausen wrote at 2006-8-13 23:09 +0200: ... forker.shutdown_zeo_server(adminaddr) File src/ZEO/tests/forker.py, line 182, in shutdown_zeo_server s.connect(adminaddr) File string, line 1, in connect error: (22, 'Invalid argument') Looks as if adminaddr where not a tuple consisting of a string and an integer. -- 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: OT: pytz
Florent Guillaume wrote at 2006-8-7 12:53 +0200: On 5 Aug 2006, at 22:38, Dieter Maurer wrote: Florent Guillaume wrote at 2006-8-5 00:17 +0200: Stuart Bishop wrote: ... I've been wondering if making pytz work like this was a correct decision. It seems that people who know enough to care about DST transition periods generally work in UTC anyway What makes you say that? Any application where datetimes are user-entered and user-visible will certainly *not* want to store them in UTC, as users will want dates displayed as they were entered (meaning holding their original timezone, even if the timezone is not displayed). *nix recommends to store the time in UTC (in the hardware clock). Nevertheless, users see and can enter the time in their local timezone. Unix has nothing to do with an application manipulating proper calendaring concepts. The original timezone information can be quite important, and the local timezone of the user seeing the information may not be the appropriate one. This demonstrates that the storage format can be independent of what the user sees or enters... Provided all you want is store an instant in time. Which is only a limited subset of what can be useful in general. A look at iCal (RFC 2445) shows that you can either use UTC (maybe with a tacit knowledge about the timezone of the location the calendar event applied to in order to get its local time) or explicitely use the TZID parameter (such that an interesting interpreter can convert to UTC). Only when you give the timezone an implicit (!) meaning (e.g. it's the timezone applying to the location of the event) you get more than with UTC alone. -- 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: OT: pytz
Florent Guillaume wrote at 2006-8-5 00:17 +0200: Stuart Bishop wrote: ... I've been wondering if making pytz work like this was a correct decision. It seems that people who know enough to care about DST transition periods generally work in UTC anyway What makes you say that? Any application where datetimes are user-entered and user-visible will certainly *not* want to store them in UTC, as users will want dates displayed as they were entered (meaning holding their original timezone, even if the timezone is not displayed). *nix recommends to store the time in UTC (in the hardware clock). Nevertheless, users see and can enter the time in their local timezone. This demonstrates that the storage format can be independent of what the user sees or enters... -- 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] session state issues
Roy Mathew wrote at 2006-7-11 17:36 -0700: I have what seems to be an odd problem with persistence of information in simultaneous sessions. I keep track of an iterator in an object that is persistent (one instance per-session). The iterator is updated as the user navigates a sequence of objects. The iteration seems to work fine for a single user. If 2 users A and B access the system simultaneously, each users navigation is occasionally thrown off (ie: the session seems to lose track of the iterator state). Iterators can get seriously confused then the object iterated over changes. Maybe, this is your problem? -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The bug fixing problem
Philipp von Weitershausen wrote at 2006-7-6 21:35 +0200: ... If you follow the argument that untested code is broken by definition, I do not follow it. then you essentially have no fix if you get a fix without knowing whether it actually works. In many cases, I can convince myself that a fix does actually work without performing a test -- at least in the sense that it removes one bug. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The bug fixing problem
Philipp von Weitershausen wrote at 2006-7-6 18:29 +0200: ... fixing a trivial error without a unit test ... How would you make sure that your fix for even a trivial NameError actually works? Perhaps you introduced another typo in the bugfix? Obviously, I have considerable more confidence in my ability to fix bugs than you do... Or perhaps another problem pops up in the same codepath. Right, that would be possible. But, at least, one bug was fixed... Clearly, since the NameError didn't occur in any other tests, the codepath hasn't been tested yet, so it should be no matter what. If the test is as trivial as the fix, then one can easily add it (if one is not confident that the bug is truely fixed). If not, the about a quarter to half an hour timeframe is easily exhausted and if you insist on the test, you get neither the test nor the fix. There's another aspect to tests for bugs: reproduceability. Especially when fixing bugs I tend to write tests first in order to be absolutely sure that I can reproduce the problem in an automated manner. Then fixing the bug is easy: Just make the test pass... You use the personal form correctly. Not everybody does it like you do. When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. -- 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: The bug fixing problem
Lennart Regebro wrote at 2006-7-6 20:03 +0200: On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. Sure. The point of the tests is not to prevent this. The point of them is mainly to make sure that the thing you fixed says fixed. I hear (also) other sounds than unit tests ;-) Thus, my fixes can say fixed differently (without a passing unit test)... -- 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] The bug fixing problem
Christian Theune wrote at 2006-7-5 11:46 +0200: ... Another thing are the rules about unit tests. Some bugs touch areas that are poorly tested. When I fix a bug over there, do I have to work harder to introduce the fix because I have to start introducing tests? We should find and announce a reasonable answer for the procedure in this case. Although I have (so far) never fixed a bug in Zope 3 (but posted several patches for Zope 2), I can confirm this: There are bugs that do not need a test once they are fixed. All kinds of NameError and AttributeError fall into this category. Requiring to write a unit test for these or similarly trivial bugs is silly -- especially if there is not yet a testing file for the module (such that a trivial test would suffice). -- 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] AssertionError in ZEO cache
Sven Schomaker wrote at 2006-7-4 14:21 +0200: ... I just upgraded to Zope 3.2.1 and changed my setup to use a ZEO backend. This results in the exception below. Returning to the standard FileStorage backend everything works fine. ... File /usr/local/Zope-3.2.1/lib/python/ZEO/ClientStorage.py, line 999, in _update_cache self._cache.invalidate(oid, version, tid) File /usr/local/Zope-3.2.1/lib/python/ZEO/cache.py, line 367, in invalidate assert tid is not None and cur_tid tid AssertionError This error has been discussed several times on zodb-dev. You may search for it in the archive. Almost surely, the code should be cur_tid = tid rather than cur_tid tid. But there is nobody that is sure about it. -- 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] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
Tim Peters wrote at 2006-6-17 14:50 -0400: ... The problem arises because what _Python_ calls int is what C calls long, but the I-flavor BTree code stores C int, and C int doesn't correspond to any Python type (except by accident on 32-bit boxes). Why not simply change this, i.e. let BTree use what Python calls an int (i.e. a C long). Of course, we need to be a bit careful, when we load pickles. They might have been written by applications with a longer C long than we have. But, this problem we have anyway (independent of BTrees). -- 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] selecting the translation domain in ZCML
Jean-Marc Orliaguet wrote at 2006-5-30 22:13 +0200:
...
Dieter Maurer wrote:
...
In my view the translation domain is vital for translators --
as the domain guides the correct translations.
...
But it is the application that eventually sets the domain name to use,
based on the context. Translators have no control over it, since they
have no control over page templates or over python code.
You are right, of course: translators do not chose the domain
but are informed about it. However, this does not contradict
that the translation domain is specified in the .po file -- as
the translations in this file are only valid in the
translation domain for which they have been made...
...
My view is that the translations can still be stored in different
folders (one per translation context as you mentioned) and the domain
can be set in ZCML during the configuration of the application for an
entire folder, globally.
I do not disagree.
Hence, the translators are only concerned with putting translations into
folders ('business_terms', 'furniture', ...), no matter what the domain
name will be called.
But why would you want a different domain name than that communicated
to the translators? Do you prefer meaningless over strong names?
--
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] selecting the translation domain in ZCML
Jean-Marc Orliaguet wrote at 2006-5-30 12:01 +0200: ... although -- while thinking about it, putting the domain name in .po files breaks the separation on concerns between translators and application developer. Translators shouldn't have to worry about translation domains. That's application specific. Are you sure? In my view the translation domain is vital for translators -- as the domain guides the correct translations. For example, in German we have the word Bank. It may mean bench or bank, depending on the translation domain. -- 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: TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote at 2006-5-24 18:16 +0200: ... Yup. We could think about this for some future release cycle, though. I'd very much be in favour of making nocall: the default and introduce something like call:. Then sniffing for callableness wouldn't be necessary. You are aware how many templates you would break? -- 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] TALES PathExpr doesn't call old style classes
Philipp von Weitershausen wrote at 2006-5-23 17:02 +0200: ... callable() isn't even deprecated yet, so if it solves our problem, we can use it IMO. Note that Zope 3 deliberately doesn't use it because of the proxy problem. Zope 2 works around that by stripping proxies/wrappers first (ob.aq_base). Perhaps Zope3 should do that as well. Would callable(removeAllProxies(obj)) be harmful in any way if you end up calling the proxied obj() anyway? At least earlier, callable had a problem: some objects where apparently callable but calling them resulted in AttributeError: __call__. That's why cDocumentTemplate grew a safe_callable. -- 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] TALES PathExpr doesn't call old style classes
Dmitry Vasiliev wrote at 2006-5-23 17:06 +0400: ... PEP-3100 suggest just call the object and catch the exception instead of use callable(). So maybe we can write: try: ob() except: pass return ob Unfortunately exceptions still will be masked. Yes, and therefore *NEVER* do this. -- 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: Google SoC Project
Jim Fulton wrote at 2006-5-9 07:22 -0400: ... Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. Moreover, if the component performs is own reregistration on reload, the Z2 refresh may be possible as well. We use the Z2 refresh all the time and are very satisfied. Of course, with a component (i.e. Product in Z2), all dependent components have to be refreshed as well. We do this with a little tool of ourselves. With a decent dependancy spec, almost all refresh behave as expected. ... I'm really not interested in a reload faclity, like the one commonly used in Zope 2, that is not robust. I've wasted too many hours helping people debug problems that were caused by reload misshaps. I hear of very few problems here. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[2]: [Zope3-dev] Re: Google SoC Project
Adam Groszer wrote at 2006-5-9 14:36 +0200: ... [snip] JF Python simply does not support a general robust reload, other than JF restart. [snip] What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same problem, so all Python developers would benefit from the solution. As I know (that may be wrong) not many even if any language supports that, so that would make one big plus point on the Python side also. I fear, this is a very deep (and difficult) problem! A reload may modify an object that is used in arbitrary places. and Python may not know all these places... Because of this, Python has only two options: * it creates a new object and leaves all using contexts alone. That is what Python does now. * it overwrite the object in place. But for many modifications this is impossible (e.g. if the new object needs more contigous space then the old one). -- 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] RFC: Use ConfigParser for High-Level Configuration
Stuart Bishop wrote at 2006-3-20 10:38 +0700: Also, there is only one schema.xml so multiple components can't each insert their own blob of configuration information into the global schema. Please read From: Tres Seaver [EMAIL PROTECTED] To: zope3-dev@zope.org Subject: [Zope3-dev] Re: httpgz in zope.conf? Date: Mon, 20 Mar 2006 09:53:52 -0500 There, you will learn that components don't need to insert anything into the global schema but can put these things into their local components.xml. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
