Re: [Zope-dev] Proposal: Align Zope 2 and Zope 3 permissions
Martin Aspeli wrote at 2009-4-12 18:31 +0800: Finally, there is not total parity between Zope 2 security and Zope 3 security. Zope 2 cannot protect 'property set', for example. Since Zope 2.8, Zope 2 could in principle -- and until quite recently I thought, it really can: it only fails with the context check (is the accessed object in the context of the UserFolder authenticating the current user). Of course, such checks fail for objects not acquisition wrapped. If we let pass this check in such cases, Zope 2 can protect property sets. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Align Zope 2 and Zope 3 permissions
Martin Aspeli wrote at 2009-4-12 18:31 +0800: ... 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere. Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice. You probably should be careful with this: if not done carefully, you may end up doing the utility lookup not once but once at each object on the path from the accessed object to the root. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] iterating over class without __iter__ but with __getitem__ raises AttributeError:__iter__
Chris Withers wrote at 2009-4-13 03:14 +0100: The context for this is trying to get ParsedXML 1.5 running on Zope 2.12 under Python 2.5 (don't ask why!) Anyway, ParsedXML has a class: class ManageableNodeList(ManageableWrapper, DOMProxy.NodeListProxy, Acquisition.Implicit): A wrapper around a DOM NodeList. meta_type = Manageable NodeList # redefine to get back the [] syntax with acquisition, eh? def __getslice__(self, i, j): return self.wrapNodeList(self._node.__getslice__(i,j)) # redefine to get back the [] syntax with acquisition, eh? def __getitem__(self, i): return self.wrapDOMObj(self._node.__getitem__(i)) If you try and iterate over an instance of this class, you get an AttributeError: __iter__. This doesn't make a lot of sense, since you *don't* get an error like that if you iterate over an instance of: class X: def __getitem__(self,i): return 1 I'm wondering there's some ExtensionClass or similar weirdness happening here? (It didn't used to happen under Zope 2.9/Python 2.4) It does not go wrong with Zope 2.11/Python 2.4, neither. Maybe, changes done for Python 2.5/2.6 compatibility broke something. Here is a simpler script to check for problems: from Acquisition import Implicit class C(Implicit): def __getitem__(self, i): return self.l[i] l=[1,2,3] c=C() iter(c) list(_) c2=C().__of__(c) iter(c2) list(_) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Martijn Faassen wrote at 2009-4-10 18:33 +0200: Is anyone interested in maintaining Zope 3? You should leave a bit more time before you take any drastic actions... There are holidays, time of intensive other activity, ... * the thing that has some kind of documentation website - do you care about providing documentation for Zope 3 as opposed to documentation for Grok or individual libraries? I find http://apidoc.zope.org/++apidoc++/; very helpful -- for Zope 2 users. I would not like to loose it -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Don't have Zope 2 hard-specify its versions!
Hanno Schlichting wrote at 2009-4-11 14:35 +0200: ... In all other debates we seemed to agree on not over specifying requirements in setup.py files, I wonder why anybody still tries to follow this route. Because the way the Zope 2.12a1 egg did it has broken within a few weeks -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hanno Schlichting wrote at 2009-4-11 15:05 +0200: ... +1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies. You (Zope developers) are very fast in declaring things dead and destroy things application developers have build upon. I see myself rather as an application developer and conclude that Zope may no longer be adequate to build large applications on top of it -- applications that need to live and be maintained for many years to come. I am unconcerned with Zope 3 in particular, because I have not been an early adopter. But, I see the same behaviour also with Zope 2 and its features -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Don't have Zope 2 hard-specify its versions!
Lennart Regebro wrote at 2009-4-11 16:12 +0200: ... Does easy_install keep track of already installed dependencies and refuse to install it if it break dependencies? easy_install checks dependencies only at installation time -- for the egg that is installed (not for those that are already installed) . If yes, then i don't know, if no, then you can just install the version you want. We are in the no case. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Martijn Faassen wrote at 2009-4-8 15:31 +0200: ... In order to make Zope 2 and Zope 3 fit the pattern, it'd be nice if they had names that fit the Zope is a project, not software pattern. We could rename Zope 2 to Zope Classic, as was suggested. I think we should also rename Zope 3 to something else (that doesn't imply it's the modern future, as there are other alternatives at least as modern around that are more recently developed - we want to get out of that bind). Zope 2 and Zope 3 is not ideal but by now familiar. I do not think a renaming effort would be worth at the current time. Avoid misleading names in the future think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 developers are okay with this, let's go right ahead. I will continue to speak of Zope 2 (not Zope Classic). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] naming Zope
Wichert Akkerman wrote at 2009-4-9 10:40 +0200: Previously Shane Hathaway wrote: discussion type=bikeshed Tres Seaver wrote: WRT the Framework name: framework is a misleading name for the collection of packages salvaged from the new Coke effort: it is actually a *bunch* of frameworks, in the classic software engineering sense, along with some pure libraries. Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) +1 If you want to attract non-Zope people, then Zope Toolkit may not be optimal. The term suggests: the toolkit for Zope users. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.runner: protecting against rogue threads
Christian Theune wrote at 2009-4-3 08:45 +0200: ... I don't want to change the process structure: I only want to assure that the processes we start also quit. Then no objection from me. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
Chris Withers wrote at 2009-4-2 20:36 +0100: ... Personally, I evaluate such eggs in a sandbox, and then add them to the project-specific index once I'm sure that they work with the other software in the index: I don't use PyPI at all when building out production sites. That seems overly heavyweight for the average new user. no, sorry, you can't use Zope 2.12 with anything other than what it comes with unless you get your own egg repository running The egg-repository can be a virtualenv (or even the site-packages of a standard Python installation). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setting missing minimum version in setup.py
Chris Withers wrote at 2009-4-2 20:42 +0100: ... KGS the concept is very easy to implement; you just make available on some URL a buildout versions.cfg, or you run your own package index. OK, the former I can see happening on an end-user project, the latter is just too much work. Tres has earlier proposed a meta egg to represent versions.cfg in a setuptools only (non buildout) environment. A meta egg is an egg that only list dependencies and does not contain code of its own. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 4.0, maybe not such a bad idea...
Chris Withers wrote at 2009-4-2 21:29 +0100: Andreas Jung wrote: Andrew others have been working on this issue at the sprint. There is consensus that www.zope.org must be turned into landing page with some mission statement and then links to the related subprojects. The current zope.org site should be moved to old.zope.org (it must remain available for the time being (with URL redirections to the Products and Member area). Why does it need to keep living even at old.zope.org? Because members put there content (product implementations) still usable? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
Marius Gedminas wrote at 2009-4-3 01:34 +0300: On Thu, Apr 02, 2009 at 07:31:00PM +0100, Chris Withers wrote: So, svn.zope.org causes me pain at the moment: - it uses the bizarre svn or svn+ssh protocols, which I find annoying (ports blocked on routers, can't check with a browser, etc) +10 for continuing to support svn+ssh, it's the best thing ever! * secure (passphrase-protected key) * convenient (ssh-agent means you only type the passphrase once) * convenient to use remotely (ssh agent forwarding means I ssh into a remote server and can use svn without having to store a key or a password anywhere on that remote server) The story may be different for Windows users (as usual). +0.5 for alternatively accepting authenticated https access (I'm not the admin, so it doesn't cost me, but I'm also not going to use it) Unless newer SVN versions improved on this: using different access protocols is hampered by svn:external as they were (still are?) required to be absolute urls (including the protocal). This way, the access protocol may change in between of a checkout (involving svn:externals). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.runner: protecting against rogue threads
Christian Theune wrote at 2009-4-2 13:30 +0200: if tests spawn non-daemon threads, then the test runner can get stuck. The easiest way that I see is to always --exit-with-status and to make --exist-with-status also call sys.exit() when the tests passed. I do not understand the implication. Do you plan that any test runs in a separate process? Then, I would have an objection -- test suites would take far longer. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
Chris Withers wrote at 2009-4-2 19:44 +0100: ... I prefer using password-protected (as opposed to key-protected) https. What do other people prefer? I am fine with the ssh access. True, the initial setup was a bit difficult (the key program did not like the . in d.maurer -- but forgot to tell so) but Jim spare enough time to help me overcome the problem. After I changed my username from d.maurer to dmaurer, everything worked immediately. I would not like to enter my password every time I call svn. If this can be arranged, I am content. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
Jacob Holm wrote at 2009-4-2 20:44 +0200: ... For write access I completely agree. For read-only unauthenticated access it would be nice to be able to use http(s). It may be possible to have it all at the same time. I have been told that there are mirrors of the Zope SVN repository providing read access via http. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and Cygwin
Cesar Canassa wrote at 2009-3-30 14:54 -0300: It would be possible to modify the plonectl script in order to make it run without using the zdaemon? As someone modified zopectl to run under Windows without zdaemon (in newer Zope versions), it should be possible to change plonectl in a similar way. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Two small convenience suggestions for zope.interface and zope.component
Martin Aspeli wrote at 2009-4-1 22:02 +0800: I'd like to add support for the following: 1) Provider decorator: @provider(IFoo) def some_function(context) pass I have already searched for this several times -- and was disappointed about my failure :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] trying out the buildout-based Zope 2.12...
Chris Withers wrote at 2009-3-27 16:02 -0500: ... Got zope.principalregistry 3.7.0. While: Installing zopetest. Error: There is a version conflict. We already have: zope.component 3.5.1 but zope.app.security 3.7.0 requires 'zope.component=3.6.0'. Okay, so I thought I'd be smart and try the following buildout.cfg: ... What the hell is zope.app.security 3.7.0 doing being dragged down? Is this a buildout snafu? Jim? I fear we will have to learn to live with version conflicts until we are ready to pin each and every version used, either in the buildout itself or via a KGS (Known Good Set index). If we let buildout/setuptools decide which version to use, there is a good chance that it gets it wrong. The problem would be far smaller if setuptools (yes, this is the major component to blame in this case, not buildout) would first construct the complete dependency graph and then try to search a global solution. Unfortunately, setuptools resolves dependancies incrementally (not globally): when it has to handle a dependency, it tries to find a distribution satisfying the requirements taking into account the distributions it already has -- but not the dependency requirements it will also have to satisfy in a short time. This way, it may take a distribution that after a short while will conflict with another dependancy requirement. Your observation above might (other chains are possible) result from: Some dependency specifies: zope.component==3.5.1. Later some dependancy specifies: zope.app.security setuptools looks what distribution it can choose. Lacking a more specific prescription, it uses the newest one zope.app.security==3.7.0. Later, it tries to resolve the dependencies of zope.app.security==3.7.0 and finds zope.component==3.6.0. Conflict! To avoid the conflict, setuptools would need to backtrack and revise its distribution decision for zope.app.security or alternatively first build the complete dependency graph and search a global solution. However, finding such a global solution requires a complex algorithm at least when efficiency is important (which probably is the case as the dependency graphs for larger applications will be huge). Thus: I appreaciate much your wish to solve this problem but expect that it will be quite complex. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope and Cygwin
Cesar Canassa wrote at 2009-3-27 19:56 -0300: Does Zope requires that a root user should exist on system in order to run properly? I am asking this because when I try to run Zope as a daemon I got this: $ ./plonectl start instance: . . . . . . . . . . . . . . . . . . . Unlinking stale socket /cygdrive/c/Cygwin/home/ccanassa/Plone/zinstance/var/instance/zopectlsock; sleep 1 No handlers could be found for logger root . Unlinking stale socket /cygdrive/c/Cygwin/home/ccanassa/Plone/zinstance/var/instance/zopectlsock; sleep 1 . Unlinking stale socket The continued Unlinking stale socket means that your zdaemon is dieing. zdaemon is not supposed to work under Windows. I am unsure whether this also includes Cygwin on Windows. Your observation may indicate that it actually does Try to configure logging for your zdaemon and look into its logfile. If this does not reveal hints, modify the zdaemon code to ensure that problems are logged to a file you know. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] trying out the buildout-based Zope 2.12...
Jim Fulton wrote at 2009-3-29 12:02 -0400: ... 2. Backtracking is more practical in buildout than with easy_install. easy_install (not sure about pip) does conflict detection/resolution at run time, whereas buildout does it at build time. Slow conflict resolution is a lot more practical when you don't do it every time you start a script. Are you sure? I think setuptools usually only searches for distributions during installation time. Runtime distribution searching is restricted to the require call and relevant only for multi version eggs. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py extra dependencies
Christian Theune wrote at 2009-3-23 14:44 +0100: ... I usually just run the tests that I'm interested (-s or -t or a combination) in during those times. I never had to go in and comment out a test_suite function. I had when I had run the ZODB test suite. Some tests deterministically had hang -- and I had to exclude them from the suite to get a result from the total suite. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Zope 2.12] distribution broken
In order to test my external 'ZClasses' implementation,
I easy_installed Zope2 (about 1 hour ago) -- but unfortunately,
the distribution is broken: version conflict zope.component 3.5.1 versus
zope.component 3.6.0.
Maybe, the eggification of Zope2 will not turn out to be an advantage --
at least not when installed via easy_install from PyPI (i.e. without
a KnownGoodSet index)
(zcpython)newdm: mkzopeinstance
Traceback (most recent call last):
File /home/dieter/ZopeSVN/ZClasses/zcpython/bin/mkzopeinstance, line 5, in ?
from pkg_resources import load_entry_point
File
/home/dieter/ZopeSVN/ZClasses/zcpython/lib/python2.5/site-packages/setuptools-0.6c7-py2.5.egg/pkg_resources.py,
line 2564, in ?
for dist in working_set.resolve(
File
/home/dieter/ZopeSVN/ZClasses/zcpython/lib/python2.5/site-packages/setuptools-0.6c7-py2.5.egg/pkg_resources.py,
line 528, in resolve
raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (zope.component 3.5.1
(/home/dieter/ZopeSVN/ZClasses/zcpython/lib/python2.5/site-packages/zope.component-3.5.1-py2.5.egg),
Requirement.parse('zope.component=3.6.0'))
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Zope 2.12] how to test products/packages?
The Zope 2.12 documention tells that the test command was removed from zopectl. test was a convenient way to test products and packages in the context of the instance. How is this use case now supported? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [Zope 2.12] Packaging weakness
The documentation on PyPI tells to look into doc/INSTALL.txt to find installation instructions. However, doc is not installed by the standard easy_install process. Therefore, it is not so easy to find it. Relevant documentation should be installed by the standard easy_install process (it should be part of the installed egg). I will file a bug report. Minor note: the installation instructions are actually in INSTALL.rst not INSTALL.txt. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] how to test products/packages?
Andreas Jung wrote at 2009-3-15 08:53 +0100: On 15.03.2009 8:31 Uhr, Dieter Maurer wrote: The Zope 2.12 documention tells that the test command was removed from zopectl. Have to investigate that. test was a convenient way to test products and packages in the context of the instance. How is this use case now supported? Go with the buildout approach and use the alltests.cfg for testing support (see alltests.cfg). Means: work with a SVN checkout. I do not want to test Zope, I want to test *MY* Zope based components. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] Packaging weakness
Andreas Jung wrote at 2009-3-15 08:56 +0100: ... On 15.03.2009 8:36 Uhr, Dieter Maurer wrote: The documentation on PyPI tells to look into doc/INSTALL.txt to find installation instructions. However, doc is not installed by the standard easy_install process. Therefore, it is not so easy to find it. Relevant documentation should be installed by the standard easy_install process (it should be part of the installed egg). All related docs are available from our new place: http://docs.zope.org/ Hint: then the PyPI page should get considerable overhaul: * It should point to http://docs.zope.org;. Instead, it currently points to http://www.zope.org/Documentation/; where no current installation instructions can be found * It should indicate that unlike natural expectation, the packagers of the Zope2 egg decided to put the installation instructions not into the eggs but instead on the internet. And as this is a new place, a link there would be appropriate. * Maybe, it should warn people agaist easy_installing Zope2 -- as the developers did not yet care much about this distribution way and the installed egg may not work. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] how to test products/packages?
Hanno Schlichting wrote at 2009-3-15 11:10 +0100: Dieter Maurer wrote: The Zope 2.12 documention tells that the test command was removed from zopectl. test was a convenient way to test products and packages in the context of the instance. How is this use case now supported? The normal way to develop anything in the Zope world is based on zc.buildout today. You can define a testrunner like this: I do not have good experience with buildout and will try to avoid it. I will probably resurrect the old way to run tests in the same way I will resurrect ZClasses (i.e. though an externally maintained PyPI package). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] distribution broken
Andreas Jung wrote at 2009-3-15 08:48 +0100: ... Zope2 2.12.1a1 version conflict ... ... In addition: setuptools 0.6c7 is pretty old and known to be broken in some ways. As expected, setuptool 0.6.c7 was not the problem. After easy_install -U setuptools, an easy_install -U Zope2 leads to (zcpython)newdm: easy_install -U Zope2 Searching for Zope2 Reading http://pypi.python.org/simple/Zope2/ Reading http://www.zope.org Best match: Zope2 2.12.0.a1 Processing Zope2-2.12.0.a1-py2.5-linux-i686.egg Zope2 2.12.0.a1 is already the active version in easy-install.pth Installing zpasswd script to /home/dieter/ZopeSVN/ZClasses/zcpython/bin Installing mkzeoinstance script to /home/dieter/ZopeSVN/ZClasses/zcpython/bin Installing mkzopeinstance script to /home/dieter/ZopeSVN/ZClasses/zcpython/bin Using /home/dieter/ZopeSVN/ZClasses/zcpython/lib/python2.5/site-packages/Zope2-2.12.0.a1-py2.5-linux-i686.egg Processing dependencies for Zope2 Searching for zope.component==3.5.1 Reading http://pypi.python.org/simple/zope.component/ Best match: zope.component 3.5.1 Downloading http://pypi.python.org/packages/source/z/zope.component/zope.component-3.5.1.tar.gz#md5=006c43ad77ed4982e49c07f6e65b68a2 Processing zope.component-3.5.1.tar.gz Running zope.component-3.5.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-KtgqcP/zope.component-3.5.1/egg-dist-tmp-3BefxU Adding zope.component 3.5.1 to easy-install.pth file Installed /home/dieter/ZopeSVN/ZClasses/zcpython/lib/python2.5/site-packages/zope.component-3.5.1-py2.5.egg error: Installed distribution zope.component 3.5.1 conflicts with requirement zope.component=3.6.0 -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] distribution broken
Andreas Jung wrote at 2009-3-15 08:48 +0100: ... Zope2 2.12.0a1 distribution broken ... ... Try using the traditional python bootstrap.py bin/buildout approach. That (magically) worked. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope 2.12] how to test products/packages?
Andreas Jung wrote at 2009-3-15 18:36 +0100: ... test was a convenient way to test products and packages in the context of the instance. How is this use case now supported? Go with the buildout approach and use the alltests.cfg for testing support (see alltests.cfg). Means: work with a SVN checkout. I do not want to test Zope, I want to test *MY* Zope based components. Then write *your* dieter.cfg containing [buildout] extends = buildout.cfg parts += alltests [alltests] recipe = zc.recipe.testrunner eggs = dm.foo.bar and run buildout -c dieter.cfg My experience with buildout is not good. I want to avoid it. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Tres Seaver wrote at 2009-3-11 21:27 -0400: ... In packages that don't load their own ZCML during the tests, it's harder to say. One reaction could be that this package doesn't have enough tests then! Of course another would argue that this is configuration information only that can be overridden, but it is rather special configuration... - -1 on having configuration dependecies, including having mandatory tests that ZCML will load: mandatory configuration is a contradiction in terms. I therefore don't believe that tests which try to load ZCML are useful, at least for library pacakges (as opposed to applications). I do not agree with you here. *IF* a package contains ZCML files (e.g. in order to facilitate a standard integration into a larger Zope 3 system), then these ZCML files should of course be tested -- even when there are conceivable package uses that do not use the ZCML files. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Tres Seaver wrote at 2009-3-12 14:25 -0400: ... Sorry, I meant mandatory tests which load ZCML. I'm actually against ever loading ZCML in tests at all. If you ship ZCML, you should test it, no? You will not ship ZCML, but this may not apply to everybody -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies for ZCML
Tres Seaver wrote at 2009-3-13 16:20 -0400: ... Dieter Maurer wrote: Tres Seaver wrote at 2009-3-12 14:25 -0400: ... Sorry, I meant mandatory tests which load ZCML. I'm actually against ever loading ZCML in tests at all. If you ship ZCML, you should test it, no? Not necessarily: in fact, if testing it means that users of my package have to accept a big dogpile of dependencies that they otherwise wouldn't need to, then no. Your and my quality principles diverge: If I release a package, then its tests have the verify that the package contents work correctly. This implies: the tests should cover everything the package delivers including delivered ZCML files and optional features. The tests are my tool (as developper of the package) to help me find and fix errors before the release. I am completely uninterested to facilitate testing of reduced or otherwise special use of my packages. If the full tests pass then a reduced use should work as well (provided the integrator did everything right). If the user is interested to verify for his own that the tests pass, I expect of him to test the full functionality -- or not use the package at all. To stress it: the above just describes test requirements -- not install requirements. I am ready to support loose install requirements (and use extras to support optional features) but I am not ready to invest in loose test requirements. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Question: additional context for IAnnotations adapter?
Jacob Holm wrote at 2009-3-6 01:55 +0100: ... I added it while working for ZC two years ago. It was needed to support a use case where the context used for looking up the annotation was not necessarily the current site. I don't know if the use case is still relevant to ZC, but the pattern is still being used in e.g. zc.notification and zope.app.preference (where it was added by me at the time). I expect that use cases like this (looking up objects in a foreign site context) will be important for my current employer (if it continuous to use Zope in the future). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] deprecating the deprecation system?
Roger Ineichen wrote at 2009-3-8 14:38 +0100: ... Can you give an example of a meaningless deprecation warning? A few of the deprecations I have disliked for a long time: /home/dieter/Z/Products/Archetypes/__init__.py:15: DeprecationWarning: The module, 'Products.CMFCore.CMFCorePermissions' is a deprecated compatiblity alias for 'Products.CMFCore.permissions'; please use the new module instead. from Products.CMFCore import CMFCorePermissions Why should I bother about deprecations in foreign packages (Archetypes in the case above)? /home/dieter/Z/Base/lib/python/Products/CMFCore/utils.py:667: DeprecationWarning: format_stx() will be removed in CMF 1.6. Please use StructuredText.StructuredText.HTML instead. Why should the short format_stx no longer be supported and instead the monster StructuredText.StructuredText.HTML be used? And here is my favorite: /home/dieter/Z/Products/HaufePortalBase/__init__.py:86: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: HaufePortalBase The product_name parameter used to be mandatory -- thus all calls to ToolInit had to use it. Then, a means was found to derive it automatically from the context. The developper was so happy that he wanted all others immediately drop the parameter -- result: several dozens of deprecation warnings for each start -- in trivial cases, where the automatically derived information was identical to the explicitly provided I called out what a stupidity -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 00:36 +0100: ... * how will the community make hard decisions where lots of people disagree? You try to achieve consensus. When you do not, you get the chance that people turn away. ... * who reminds us of necessary tasks and directions we're going into? Beside the reminders, you need people that do the work. For this, at least, these people must be convinced. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote at 2009-3-3 17:21 +0900: ... How many times have we gotten bogged down in semantics or naming discussions and killed off the momentum behind something? A clear notion of semantics and well chosen names are important for any project. I would not want momentum resulting in confused semantics and misleading names. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 22:11 +0100: ... backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. Large applications are built upon the framework. If the framework too often drifts away, the maintenance costs for these applications gets too high -- and make the framework unattractive. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] deprecating the deprecation system?
Martijn Faassen wrote at 2009-3-5 17:35 +0100: Perhaps it's time to deprecate the deprecation system. ... Thoughts? +1 -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py extra dependencies
Dan Korostelev wrote at 2009-3-5 22:14 +0300: ... -0.75 for removing functionality extras. I still don't get how extras are different from additional packages. I agree with Dan -- and add -1. The extras are equivalent to almost identical additional packages. If this makes reasoning more difficult, expand the graph in the trivial way before you start the reasoning. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote at 2009-3-2 12:11 -0500: ... I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. + 1 Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility - 1 I think that a high level of backward compatibility is important. You do not want to continously rewrite your applications because the framework continously drifts away style policing, historical ownership) + 1 - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). + 1 ... although I quite often complain about changes (such as the removal of ZClasses, the (temporary) removal of the logging interface, ) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope2book/trunk/ Lot's of updates over the weekend!
Andreas Jung wrote at 2009-2-16 19:50 +0100: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.02.2009 19:43 Uhr, Dieter Maurer wrote: Andreas Jung wrote at 2009-2-16 19:20 +0100: ... Please come off it. Either become an active contributor and participate in our dictatorship I will never participate in your dictatorship! How childish. I hate dictatorship - consequently I will not participate. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope2book/trunk/ Lot's of updates over the weekend!
Jens Vagelpohl wrote at 2009-2-16 20:43 +0100: ... On Feb 16, 2009, at 19:43 , Dieter Maurer wrote: Andreas Jung wrote at 2009-2-16 19:20 +0100: ... Please come off it. Either become an active contributor and participate in our dictatorship I will never participate in your dictatorship! Only those who participate can influence the direction. As I will make it with ZClasses, I will participate outside your circles. Thus, you may dictate and I fight your dictatorship -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
Zvezdan Petkovic wrote at 2009-2-19 13:06 -0500: I can adapt to any style and believe that the fine grain details should not be dogmatically enforced but rather allow for variations in such subjective preferences. +1 -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope2book/trunk/ Lot's of updates over the weekend!
Tres Seaver wrote at 2009-2-15 10:45 -0500: ... At the moment, the book is largely a guide to what can be done with Zope TTW. DTML is still part of that store: it isn't gone, nor even deprecated: its just that most core developers prefer not to use it in most cases. Note that there is still no replacement for DTML for at least one major TTW use case (SQL methods). In addition, CSS and Javascript is easier generated with DTML than with page templates. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope2book/trunk/ Lot's of updates over the weekend!
Tres Seaver wrote at 2009-2-15 11:03 -0500: ... I would rather make the case, explaining the tradeoffs, including the fact that the consensus of the community is as you express, but then let people make up their own minds. +1 I hate the tendancy of quite a few Zope core developpers to dictate how others should develop *their* applications. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope2book/trunk/ Lot's of updates over the weekend!
Andreas Jung wrote at 2009-2-16 19:20 +0100: ... Please come off it. Either become an active contributor and participate in our dictatorship I will never participate in your dictatorship! -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Hanno Schlichting wrote at 2009-2-8 14:14 +0100: Wichert Akkerman wrote: I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE. For environments like GAE you don't want setuptools and its magic to be part of your application. This is were repackaging your entire app into one zipped egg or some other flat structure comes in handy. But you can do that (packaging everything into a single zip) at home -- and can interpret extras there (without a need to have setuptools to call in your deployment environment. Setuptools and eggs are a distribution format from my point of view. They are certainly not the best way to deploy your applications. The growing sys.path is affecting performance to some degree in all deployment environments. I think your single zip would not mind whether it were build from a flat egg structure or from one with :extra -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Jim Fulton wrote at 2009-2-8 13:00 -0500: ... IMO, introducing an extra is like introducing a new package and in a rather complicated way. I agree with the first part of your sentence -- but cannot follow you with the second part: How can 'extra' : sequence of required distributions be more complicated than creating, maintaining and distributing a complete package? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Jim Fulton wrote at 2009-2-10 14:01 -0500: On Feb 10, 2009, at 1:49 PM, Dieter Maurer wrote: Jim Fulton wrote at 2009-2-8 13:00 -0500: ... IMO, introducing an extra is like introducing a new package and in a rather complicated way. I agree with the first part of your sentence -- but cannot follow you with the second part: How can 'extra' : sequence of required distributions be more complicated than creating, maintaining and distributing a complete package? Because you have to remember to test each valid permutation of the package. I bet no one does. But that is the same when each extra is represented by an individual package. Then, too, you have to test each valid combination -- and few will do it. Also, users have to be aware of the extras. PyPI doesn't advertise extras I am interested in extras only when I am interested in the package itself. Of course, the package should document in some way relevant extras. nor are there standard ways to document them. I recently looked at documentation for a few standard packages on PyPI -- and apart from all using rest and a bit of classifiction, I could not detect much standard for them, too. In general, it makes an already complicated packaging system more complicated. That's something I do not get... An extra is a shorthand for a separate package with a few extra dependancies. Sure, shorthands are not strictly necessary. Sure, complexity increases slightly. Nevertheless, they are often valuable. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] multiple packages in the same namespace
Christian Theune wrote at 2009-2-7 09:36 +0100: ... According to the setuptools documentation and our experiments on the sprint, this is supposed to work and does work: When you declare a package to be a namespace package, it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages. If so, which packagea/__init__.py gets used? Only the __init__.py isn't allowed to have code is what I read from the documentation. However, extreme care must be taken to avoid name clashes. For Modules/packages with the same name it is not deterministic which of them will actually be loaded. __init__.py is just a common case of this problem. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security changes
Chris Withers wrote at 2009-2-6 12:31 +: ... I would find is very unintuitive when configuration were centralized (in subpackages of zope.configuration) rather than modular. Configuration belongs to the application or framework component that depends on this configuration not to any central component. I would normally agree, but this isn't quite as simple as that. ZCML cuts across packages in that, if you use ZCML, you want the directives for all the packages you have installed. At least, I want only the directives for the packages I have *really* installed. Think of the dependancy monster a common configuration package would be. And even when I have a package installed, I may not want its registrations (because they are inadequate for me and I want to provide my own). If you don't use ZCML, you don't want any of the directives. using -- to mean depends on, what we want is: zope.configuration ^ | zcmlforpackagez -- packagex ...which frees up packagex to be used without any ZCML Apparently, you treat zope.configuration as a namespace package and you will never install zope.configuration as a whole but only the lower packages -- that might work. Nevertheless, I find it highly unintuitive to rip of the configuration and put it at a completely different place. Package names of the form packagex and packagex_zcml seem far more intuitive for me. Note that below zope.configuration you have to retain the namepaces of your packages to avoid name conflicts and provide a homogenous map between package and its configuration package. You would get subpackages zope.configuration.zope.proxy, zope.configuration.z3c. Nasty -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.app.component/trunk/ Please, don't just remove things that could be used in users code.
Dan Korostelev wrote at 2009-2-6 14:10 +0300: ... I still think we need to bug developers that they need to upgrade their code with deprecation warnings, so we can eventually remove old imports. When you abuse deprecation warnings for minor cosmetic issues you risk that deprecation warnings are silenced altogether -- making even serious deprecation warnings less effective as they should be ... Let's discuss it once again :) Tres examples have been good, haven't they? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.security changes
Chris Withers wrote at 2009-1-30 18:50 +: Brian Sutherland wrote: zope.configuration.x zope.configuration.y Please don't, having namespace packages that contain files (as zope.configuration already does) breaks setuptools. Then setuptools needs fixing. But not for this purpose: I would find is very unintuitive when configuration were centralized (in subpackages of zope.configuration) rather than modular. Configuration belongs to the application or framework component that depends on this configuration not to any central component. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Andreas Jung wrote at 2009-1-21 14:55 +0100: ... TARGET=Python 2.6.X ACCEPTABLE=Python 2.5 Python 2.4.X would be basically not acceptable but could be used at your own risk using the --with-python option. ... - - removing ZClasses completely But hopefully provided by a separate package, instead. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Chris Withers wrote at 2009-1-22 09:38 +: ... One thing that myself and Shane talked briefly about on this list was re-implementing the AST manipulation as dissallow-by-default filter rather than a straight manipulation. That way, unexpected stuff should be allowed by default. The terms do not seem to match: disallow-by-default would mean that unexpected stuff would be disallowed by default. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Hanno Schlichting wrote at 2009-1-23 19:36 +0100: Wichert Akkerman wrote: Previously Tres Seaver wrote: Andreas Jung wrote: - removing ZClasses completely This is done now. Wow. This was quick! Much quicker than fixing bugs reported in the collector :-( -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Andreas Jung wrote at 2009-1-25 10:21 +0100: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25.01.2009 9:27 Uhr, Dieter Maurer wrote: Andreas Jung wrote at 2009-1-21 14:55 +0100: ... TARGET=Python 2.6.X ACCEPTABLE=Python 2.5 Python 2.4.X would be basically not acceptable but could be used at your own risk using the --with-python option. ... - - removing ZClasses completely But hopefully provided by a separate package, instead. Unless someone volunteers for doing a separate package: no. I plan to provide such a package as dm.ZClasses or (maybe) Zope2.ZClasses -- of course with some complaints against the Zope release management in the documentation: * cutting away useful features without any serious need * lacking commitment wrt backward compatibility * enforcing philosophical opinions (applications should be created programmatically not via configuration only (such as with ZClasses)) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Andreas Jung wrote at 2009-1-25 12:53 +0100: ... - removing ZClasses completely This is done now. Wow. This was quick! Much quicker than fixing bugs reported in the collector :-( Please stop bitching and fix your favorite bugs in the collector. You have svn commit right *wink* I will instead try to preserse useful functionality dropped without need from the Zope core *wink*. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Martijn Pieters wrote at 2009-1-25 13:29 +0100: On Sun, Jan 25, 2009 at 12:56, Dieter Maurer die...@handshake.de wrote: I plan to provide such a package as dm.ZClasses or (maybe) Zope2.ZClasses -- of course with some complaints against the Zope release management in the documentation: * cutting away useful features without any serious need * lacking commitment wrt backward compatibility * enforcing philosophical opinions (applications should be created programmatically not via configuration only (such as with ZClasses)) Oh, please come off it. You have checkin rights and could have stepped up to maintain the code. The last necessity to do something with ZClasses was for Zope 2.8. Then, Jim did the work. There was no need now to ditch ZClasses. For me, it looks like hostility towards building applications via menues rather than programming. This is not about enforcing philosophical choices, this is about being pragmatic. If the feature was truely useful, more developers would be maintaining and fixing it. Obviously the complexity of keeping it working is outweighing it's usefulness. I do not see something obvious here. I do not know how much work Jim has invested for Zope 2.8 but I am almost sure that other efforts since then have at most been in the order of hours (probably nothing at all). You will now get an externally maintained ZClasses implementation and I am quite confident that the necessary effort will be small (though larger of course then when it remained part of Zope). If you like I report back or even better I document it. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
Andreas Jung wrote at 2009-1-25 20:19 +0100: ... Please stop the discussion. The majority of Zope developers considers the ZClasses programming model as not up2date and not flexible enough when it comes to extensibility and scalability. That's why we don't want ZClasses being part of Zope 2 anymore. We see clearly: philosophical opinions -- not complexity of keeping it working -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Roger Ineichen wrote at 2009-1-18 13:04 +0100: ... IMHO, it is not an anti-pattern: We have a global site why should we not have a global request? When Zope is used as a Web Application Server, it is quite natural to expect a request. I'm fine with the zope.globalrequest package. But it's very important to understand that this is not a common way to do things. Nobody forces you to go this way. It also makes the request/interaction etc. a part of the test setup for test components. Probably it simplifies the implementation but brings in complexity in test testing an application. We test components nowadays that need a request. Not much will change when components assume they can get a request the zope.globarequest way. We create a request object and ensure that it is delivered the zope.globalrequest way. Note that Zope 3 handles the (global) site very similar to the way zope.globalrequest handles request. This, too, does not make tests impossible (or very difficult). to the way zope.globalrequest handles request. This, too, does not make tests impossible (or very difficult). I don't say that this is bad in general. I just say that if you build an application based on zope.globalrequest, this is a totaly different base concept how you will develop applications like we do now. And you have to pay the price with a complex test setup. I can live with this complexity :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Tres Seaver wrote at 2009-1-18 11:38 -0500: ... I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request, This is not the case for localsitemanager delivered local utilities and we therefore have had several problems. while Z3 apps use the separation of concerns pattern I just outlined. Nobody forces you to go this route. I've never wanted a 'get_request' method in production code: I would consider the need for it a sign that something in the application is factored wrongly. You could use the same arguments with respect to the global site ;-) But few people in Zope 3 land separate site dependent and site independent code despite some cases where the global site does make problems. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Martin Aspeli wrote at 2009-1-17 11:36 +: Dieter Maurer wrote: Christian Theune wrote at 2009-1-16 09:06 +0100: I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder about it. IMHO this implements an anti-pattern in an official way without a warning that this needs to be handled with care. IMHO, it is not an anti-pattern: We have a global site why should we not have a global request? When Zope is used as a Web Application Server, it is quite natural to expect a request. +1 However, there is a definite risk with it as well of encouraging poor separation of concerns. If code is dependent on a request it's not re-usable outside the web container. For views or web app controllers, that's certainly fine, but if you're writing something more generic, then it may be better to have the discipline to pass objects around that properly abstract your data, rather than assume you can access the request willy-nilly. We are in Python land -- and accustomed that using our freedoms occationally has a price :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Christian Theune wrote at 2009-1-16 09:06 +0100: I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder about it. IMHO this implements an anti-pattern in an official way without a warning that this needs to be handled with care. IMHO, it is not an anti-pattern: We have a global site why should we not have a global request? When Zope is used as a Web Application Server, it is quite natural to expect a request. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Hanno Schlichting wrote at 2009-1-16 10:14 +0100: Christian Theune wrote: I noticed 'zope.globalrequest' on the PyPI RSS feed today and wonder about it. IMHO this implements an anti-pattern in an official way without a warning that this needs to be handled with care. The discussion for this happened on the plone-dev mailing list. The reasoning for the functionality is to provide a clean way to get to the request, without relying on Acquisition. Storing the request in a thread local is similar to the way other web-frameworks handle this. In addition, this is how the global Zope site is handled. It is good to be able to access both site and request in a standard way. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.globalrequest?
Chris Withers wrote at 2009-1-16 17:00 +: ... Personally, I've always seen zope.* as being usable on their own or with either Zope 2 or Zope 3. It seems this package is only usefully targetted at zope2 I am not so sure. Accessing the request in a simple standard way may be useful whenever Zope is used as a web application server -- whether it is Zope 2 or Zope 3. so a zope2.* namespace seems perfect. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
Martijn Faassen wrote at 2008-12-19 22:18 +0100: On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer die...@handshake.de wrote: Martijn Faassen wrote at 2008-12-18 16:27 +0100: ... You should, and likely are, shipping your package with a recommended list of versions. Apparently, grok was forced to go this route. But, in principle, this is undesirable. No, it's very desirable if you want to provide a stable platform at all. A platform is *not* stable if each time a new user installs it he might end up with a different set of latest versions - there's just no way to communicate about bugs if it's that way. It's also just not right to force all the users of a framework to make the determination which version to use for dozens of packages. The idea of using a framework is to make life easier, not harder. That's your point of view -- mine is different (maybe, because my frameworks are much smaller). Most of my components work with a wide version range of other components. I would not like to expose a single version. Usually, I include a narrative of the form: known to work with 2.6.x through 2.11.x; may work with other versions as well (not tested). What will you do once Zope 2 is split up into multiple packages? How would you express such a thing about Zope 3 if there is no canonical list of versions (such as KGS)? Grok is in the position of Zope 2 or Zope 3 here. My components will only depend on some of the (future) Zope 2 components in an essential way. Others may significantly change without a serious effect on my components. Thus, I will document in a way similar to tested with Zope 2.8, 2.9, 2.10; ZODB 3.2, 3.3, 3.4. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Next Step to Bug Resolution???
Tim Cook wrote at 2008-12-18 08:35 -0200: ... Yeah we use the really cool, robust, well tested and trusted application server called the Zope Component Architecture because it really shows the strengths of the open source development process. Oh, by the way, after everything is installed you have to replace a core ZCA file with the one we provide you in order to make it actually work. I often approach situations like this with so called Monkey Patches: I replace or enhance classes or methods during startup (triggered by some startup event). This may not be optimal but allows me to solve my problems without tight coupling with the core developpers who usually do not have my problems and tend not see them as very high priority. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
Martijn Faassen wrote at 2008-12-18 16:27 +0100: ... You should, and likely are, shipping your package with a recommended list of versions. Apparently, grok was forced to go this route. But, in principle, this is undesirable. Most of my components work with a wide version range of other components. I would not like to expose a single version. Usually, I include a narrative of the form: known to work with 2.6.x through 2.11.x; may work with other versions as well (not tested). In the past, I have seen excessive deprecation warnings and had the feeling that the warning feature is overused (as many new features). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers wrote at 2008-12-13 02:17 +: I have a need to be able to adapting certain objects to None, eg: def some_adapter(obj): if something: return None return somethingelse Your use case seems to abuse adaptation: Adaptation to an interface must always return an object which provides the interface. None, by default, only provides very few interfaces (not sure whether you can extend this set with 'alsoProvides'). I think that in some cases, it would be useful for an adapter factory to say 'I cannot handle this case' and then the adapter lookup is continued. Maybe, this is already supported? Then, maybe, you can use it? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers wrote at 2008-12-13 10:18 +: Dieter Maurer wrote: I think that in some cases, it would be useful for an adapter factory to say 'I cannot handle this case' and then the adapter lookup is continued. Maybe, this is already supported? Then, maybe, you can use it? That's exactly what returning None indicates... def some_adapter(obj): if something: return None return somethingelse Your use case seems to abuse adaptation: Adaptation to an interface must always return an object which provides the interface. None, by default, only provides very few interfaces ...indeed, however, I really do want to return None here. Then, use something different from adaptation (as adaptation does not fit your wishes). I expect that your adapter factory can raise ComponentLookupError when it cannot handle the adaptation and then the default argument of the adapter lookup will take effect. adapter = IMyInterface(obj, None) if adapter is None: # adaptation impossible def adapter_factory(...): ... raise ComponentLookupError() -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers wrote at 2008-12-13 10:42 +: ... From looking at the python implementation of Interface, __call__ is indicated to be the method to override, but with the C-based Interface, this has no effect. Why is that? *That's* what I'm looking for help with, not judgement on whether adapting to None is a good idea or not ;-) I am very pleased that adaptation poses some resistance to the abuse of its semantics ;-) I *DO* want that I can rely on the result of IInterface(...) really providing IInterface (and not be forced to check against all potential values others invented to circumvent the adaptation semantics). Thus, I hope, you will not get your wish :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plone/Zeocluster performances problems
Jean-Michel FRANCOIS wrote at 2008-12-8 11:17 +0100: Configuration of Zope is a pain. Take a first look there: http://blip.tv/file/315714 Apache in your case is not the problem. I think this is your zope configuration (only one thread per instance is a good thing). I do not think that the sentence inside the (...) is correct. There may be cases where one thread per instance can be recommended but in general the default (4 threads per instance) is not that bad. This is especially true when you have a bit more expensive queries against a relational database. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Tres Seaver wrote at 2008-10-17 15:14 -0400: ... verifyObject/verifyClass is likely not to handle the following case correctly: class I(Interface): def m(...): ... class C(object): implements(I) m = property(lambda self: lambda ...: ...) i.e. when a method (declared by the interface) is implemented by a property. Why would I want to do that, rather than using 'def m(self):'? Why do you want to compute (non-method) attributes rather than define them directly on the class or set them on the instance? Indeed, defining methods by means of descriptors is not uncommon. staticmethod and classmethod are prominent examples. Fortunately for verifyClass, they return function and method when resolved on a class. Would they not, verifyClass would fail (as in the property case). I have been wrong with respect to verifyObject: verifyObject handles the case correctly. I hit a (minor) error when I made some tests to answer your question: from zope.interface import Interface, implements from zope.interface.verify import verifyObject, verifyClass class I(Interface): ... def m(): pass ... class C(object): ... implements(I) ... @classmethod ... def m(): pass ... c=C() verifyObject(I, c) True verifyClass(I, C) True c.m() Traceback (most recent call last): File stdin, line 1, in ? TypeError: m() takes no arguments (1 given) I.e. the Zope3 verify does not catch that a classmethod needs an argument where the class can be passed in. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Errors / Warnings in Zope log - what to do?
Hermann Himmelbauer wrote at 2008-10-17 23:04 +0200: During testing, I found the following warnings/errors in my zope log: --- 2008-10-17T17:56:50 WARNING ZopePublication Competing writes/reads at ???: database conflict error (oid 0x06d3, class zc.queue._queue.BucketQueue, serial this txn started with 0x0379451cbf5d7bdd 2008-10-17 15:56:44.851212, serial currently committed 0x0379451ccd1f50bb 2008-10-17 15:56:48.075545) -- 2008-10-17T17:58:10 ERROR txn.1121233232 Error in tpc_abort() on manager zope.sqlalchemy.datamanager.SessionDataManager object at 0x35a4f50 Traceback (most recent call last): ... line 82, in tpc_abort raise TypeError(Already committed) TypeError: Already committed -- 2008-10-17T17:58:10 WARNING ZopePublication Competing writes/reads at /BSPSite/act/@@/bspskin-res/bankaustria.gif: database conflict error (oid 0x06e3, class zope.session.session.SessionData) -- Why is this happening? I have to admit, that I'm currently testing/implementing background tasks with lovely.remotetask - perhaps this is the reason? Perhaps it's the combination with zope.sqlalchemy? There have been problems with the (then) released version of zope.sqlalchemy (discussed in this mailing list). These problems are said to be fixed in the svn version. Do your problems also occur with the svn version? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Christian Theune wrote at 2008-10-16 20:27 +0200: ... Then again, verifyObject is a *very* light way to spot simple errors. IMHO attributes and methods aren't that different in Python, as using both may result in exceptions. Using attributes (not computed one) does not result in exceptions. However, implementing a method of an interface doesn't check whether the method actually executes correctly -- only whether an implementation is present. Of course, it does not -- because (in general) there is not a single call which would need to be checked but usually an unlimited number of calls. One may argue that a parameterless method is very similar to an attribute (Eiffel does this), but this is not the case in Python. Arguably, the check for an attribute would be sufficient if it checked whether an attribute implementation is around -- either by a simple attribute value or a descriptor providing that. Of course one can argue: Gocept argues for it and I argue against it. There's another method: verifyClass. This definitely only checks the presence of an implementation. It only checks methods and ignores everything else. For methods, it uses the same getattr as verifyObject does (in fact, both are implemented by the same function). And if the attribute is implemented by a property (of the class, i.e. the decriptor is on the metaclass), then the descriptors __get__ is called (in the same way as for verifyObject). Instance properties (descriptor on the class) may not define methods (probably a bug). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote at 2008-10-16 20:57 +0200: Christian Theune [EMAIL PROTECTED] wrote: Arguably, the check for an attribute would be sufficient if it checked whether an attribute implementation is around -- either by a simple attribute value or a descriptor providing that. At this point, I guess the outcome of the discussion depends on whether it is considered legal or abuse to implement a data descriptor in such a way that it hides an attribute defined on a base class by raising an AttributeError. That is only one extreme case. Instead, the discussion outcome depends on whether an attribute is considered to be there when the descriptor raises an exception. As the attribute is not accessible in this case, I argue that it is not there: in this case, it does not have the wrong value, it has no value at all... There's another method: verifyClass. This definitely only checks the presence of an implementation. To be more precise: the declaration of implementation of an interface as opposed to actual implementation of its attributes. Thomas: There is an issue that we regularly see with verifyClass that makes us instanciated the objects and then use verifyObject. I don't remember what it was right now. Do you? Not really, other than to avoid the case of a happy verifyClass() call with the application dying of a forgotten attribute implementation. Could there be classes we subclass that claim to implement an interface but don't fully do so until after instantiation? Just a guess... Indeed: as Python lacks a means to define instance attributes on the class, the presence of attributes can (reliably) only be checked on instances. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote at 2008-10-17 19:42 +0200: Dieter Maurer [EMAIL PROTECTED] schrieb: ... Instance properties (descriptor on the class) may not define methods (probably a bug). I don't understand what you're saying in that last sentence; can you elaborate? verifyObject/verifyClass is likely not to handle the following case correctly: class I(Interface): def m(...): ... class C(object): implements(I) m = property(lambda self: lambda ...: ...) i.e. when a method (declared by the interface) is implemented by a property. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote at 2008-10-15 20:55 +0200: Dieter Maurer [EMAIL PROTECTED] wrote: I fear your must describe your proposed change more precisely: Nothing to be afraid of here ;o) When your problem is the stated use case: verifyObject fails because something necessary for the interface to be properly implemented is missing in the test but available in a real environment, Yes, this is what I'm talking about. I would say: that is very fine: Do not change verifyObject but give the test instead the resources expected to be available in the real environment. I think this line of reasoning intermingles two different things to be tested: the existence of an implementation of an attribute (as a data descriptor, whatever its getter method tries to do), and whether the attribute's value is sensible at any given point of time. You can compare this to a plain attribute promised by an interface: if it exists on an object that claims to provide the interface, verifyObject will be happy. The attribute's particular value at the time verifyObject looks at it may still be something very stupid from the point of view of the application. The latter is the subject of a different test, not one of interface implementation. I do not follow your argumentation: An attribute it not there because there is a descriptor, it is only there when the descriptor provides a value: I have seen descriptors in Zope3 that are only there to remove an attribute that might otherwise be inherited -- by unconditionally raising AttributeError. In this case, the existance of the particular descriptor precisely means that the attribute is missing. Moreover, when an attribut is implemented by a descriptor, I am very much interested that its __get__ does not raise an exception. If this is not the case, I would like to be warned early; if possible even by a unit test. This means that I am against your proposed change. To put it differently: If I implement a class and give its instances all attributes defined by a given interface then I expect verifyObject to damn well see that those attributes are there, Computed attributes introduce a new quality: while a standard attribute is either present or absent, a computed attribute may also raise an exception (and behave exactly like an absent attribute) on access. You want to treat those attributes as present, I do not. I'm aware that this is purely from the point of view of the user and does not take into account any design discussions that may have taken place when verifyObject was created. I, too, am a user (and was not involved in the design of verifyObject). Nevertheless, I do not share your point of view. This would be better than the current behaviour, but it would still lie because of the difference between the existence of an implementation of the attribute in question and its successful execution in a given set of circumstances. Use a different method to verify your notion of adherence with an interface. Do not change verifyObject for this. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.interface: verifyObject vs properties
Thomas Lotze wrote at 2008-10-15 09:27 +0200: There has been a problem with zope.interface's verifyObject function that occurs in conjunction with Python properties: when verifyObject checks for the presence of an object's attribute, it does so by using hasattr() which in turn tries a getattr() call. If the attribute is implemented as a property, this may raise an exception which will be masked by hasattr() due to a bare except: clause. One scenario where this is a problem is a property that performs some component lookup which will succeed at application runtime but not in unit tests where verifyObject is commonly used. While it has also been argued that behaviour so complex that it may raise an Exception should not be implemented as a property in the first place, we believe that verifyObject should handle this case better than it currently does. A possible fix would be to add an additional check for a data descriptor on the object's class if the hasattr() test returns False. Are there any objections against modifying verifyObject in this way? I fear your must describe your proposed change more precisely: When your problem is the stated use case: verifyObject fails because something necessary for the interface to be properly implemented is missing in the test but available in a real environment, I would say: that is very fine: Do not change verifyObject but give the test instead the resources expected to be available in the real environment. When you want to provide a better (more informative) exception (not fails to implement but ComponentLookupError), then I am with you. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Chris Withers wrote at 2008-9-22 19:41 +0100: Shane Hathaway wrote: +1 from me as well on IFoo.adapt() with the signature Chris suggested. zope.component.getMultiAdapter() is only easy to remember if you're a die-hard Zope coder, while IFoo.adapt() seems more useful to the larger Python community. So if we're all in agreement, what happens next? We find a volunteer to work on this. For some time still, I will be very busy with gardening and have not much time for programming. Thus, I will not be a volunteer (in the near future). But, I have seen that you started work already :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: Unicode object ids and PropertyManager properties
Paul Winkler wrote at 2008-9-12 09:04 -0400: Is there a concensus on the best way in zope 2 to handle non-ascii object IDs? The current restrictions are based on a very old, gradually updated regex which still isn't right, see for example https://bugs.launchpad.net/zope2/+bug/143616 There is a branch which gets rid of the restrictions http://svn.zope.org/Zope/branches/dm-arbitrary-ids/;. It awaits wetting (special wish of Tres Seaver). ... Even if that's wrong, the ascii assumption seems to be so widespread in Zope 2 that I think, short of a full audit and a comprehensive plan, gradually using isinstance(foo, basestring) might just be false advertising that leads people into trouble. Our local Zope got rid of the ASCII restriction several years ago, mainly to support WebDAV with the same naming conventions as typical file systems (i.e. including special characters (umlauts) in names). We have met only one problem: MS-WebDAV usually does not change the encoding -- but some WebDAV operations (rename, copy) follow the recommendation of HTML 4.01 to first utf-8 encode and then url encode. Thus, we had to cope with both a native encoding and an utf-8 encoding. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy locks up transaction
Brian Sutherland wrote at 2008-9-16 09:56 +0200: I've recently seen a situation where zope.sqlalchemy locked up the transaction machinery. I'm not sure exactly what happened, but have attached a failing test for at least one bug which may have caused it. Hopefully it's self explanatory;) If someone could help me solve this, that would be great! We have seen similar problems and hope to understand/work around them soon. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy locks up transaction
Brian Sutherland wrote at 2008-9-17 12:33 +0200: On Tue, Sep 16, 2008 at 02:01:07PM +0100, Laurence Rowe wrote: Brian Sutherland wrote: Hi, I've recently seen a situation where zope.sqlalchemy locked up the transaction machinery. I'm not sure exactly what happened, but have attached a failing test for at least one bug which may have caused it. Hopefully it's self explanatory;) If someone could help me solve this, that would be great! Could you try this with latest trunk. I checked in a fix the other day that may help. I just checked in a fix, please feel free to comment on/revert it if it's not up to standard:) It looks not yet right to clear the state in tpc_vote when a two phase commit is used (which is now supported by SQLAlchemy). In addition, there may be a problem in case session.close() raises an exception. Then, _finish would not be called. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.pt/trunk/TODO.txt
Martijn Faassen wrote at 2008-9-10 11:32 +0200: ... As far as I know in XML, attributes without an explicit namespace prefix are not in any namespace at all. Default namespaces don't apply to attributes. http://www.w3.org/TR/2006/REC-xml-names-20060816/#scoping-defaulting specifies: the interpretation of unprefixed attributes is determined by the element on which they appear. The tal/metal: elements have decided that unprefixed attributes are interpreted as belonging to this namespace. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Chris Withers wrote at 2008-9-8 18:34 +0100: ... There's the backward-compatibility issue, which is a showstopper. There's plenty of code that does this: adapter = package.interfaces.IFoo(object, None) Changing the signature as you describe would break all code that does this. How about a new major revision of zope.interface then? I fear that would be a bit drastic -- for a mostly cosmetic change. But interfaces might grow an additional method, e.g. adapt, which could get the new signature. The syntax would be a bit more cumbersome -- but on the other hand, it would be more explicit :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to use UserTrack product?
Rupesh P Raj wrote at 2008-9-9 13:41 +0530: I am very newbee to Zope. In my Zope application I want to integrate UserTrack product (we dont use plone). I placed the UserTrack folder inside the Products directory, and created an instance of UserTrack inside some of the other zope products, as follows: u = UserTrack() logger(str(u.listUserActivities())) But the list is coming as empty. I think the place where I have initialised the UserTrack instance is wrong. In the Readme file which comes along with UserTrack says that, UserTrack lists the currently active authenticated users that are logged into zope and accesses an object below the folder where the UserTrack instance resides. So I guess I need to write initialize in some of the ZMI folder object, but which one?. Can anyone please help me. I do not know UserTrack and how it works. However, the README tells you, that UserTrack must reside in a folder. This means that it must be integrated into the Zope site hierarchy. Usually, you put objects into a folder in the ZMI via the so called add list. This is the selection field to the left of the Add button in the Contents tab of folder like objects. You can also do this programmatically. The idiom is destination.manage_addProduct[defining_product].constructor(args) Here defining_product is the product that defines the new object's class, constructor is the function that create the object and args are the arguments the constructor needs (usually the id of the object to be created, optionally a title). An example would be: destination.manage_addProduct['OFSP'].manage_addFile(id, content) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies and future of zope 3
David Pratt wrote at 2008-9-3 20:32 -0300: Can we also discuss the potential of only including testing setup for dev eggs and removing testing as part of a release when the eggs are packaged to pypi or other repository for consumption. -1. This would really only save disk space -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Philipp von Weitershausen wrote at 2008-9-1 14:07 +0200: ... I've personally thought for some time that it would be quite nice if all you had to do was call an interface to look up a utility (which is sort of a multi-adapter of order 0) or to do some kind of adaption, no matter how many objects you wanted to adapt. E.g.: auth = IAuthentication() # utility auth = IAuthentication(default=None) langs = IUserPreferredLanguages(request) # adapter langs = IUserPreferredLanguages(request, default=None) view = IBrowserPage((obj, request), name='index')# named multi-adapter etc. Personally I would favour such consistency higher than the current behaviour, which may have been invented intentionally but still causes confusion once in a while. I am with you in this respect (as you probably already knew) :-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Chris Withers wrote at 2008-9-1 16:23 +0100: ... auth = IAuthentication() # utility auth = IAuthentication(default=None) langs = IUserPreferredLanguages(request) # adapter langs = IUserPreferredLanguages(request, default=None) view = IBrowserPage((obj, request), name='index')# named multi-adapter Right, but how do you differentiate adapting a tuple to IBrowserPage versus adapting obj and request together to IBrowserPage? One way would be to use *objs in the Interface.__call__ signature. Then, multi-adaptation could be I(obj1, obj2, ...) and tuple adaptation I((obj1, obj2, ...)). Of course, all other parameters would need to be keyword parameters (a good thing). Do you have a serious use case for tuple adaptation? -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zipped versus unzipped eggs (was: Re: SVN: Zope2.buildout/trunk/ Don't pin setuptools.)
Tres Seaver wrote at 2008-8-28 15:22 -0400: I don't think zipped eggs are a win in any real scenario, except possibly the goofy file-count-limited GAE. I would strongly prefer that you revert this one change (you can override it in your own '~/.buildout/default.cfg'). We have observed a drastic speedup (on both Windows and Linux) in import time (about 30 %) when we have put our complete (large) application (consisting among others of Zope 2, CMF, Archetypes) in a (single) zip file. The probably reason: Python's module lookup is very expensive. It makes about 5 pokes on each entry in sys.path. These become stat for directory entries. Looking into an in-memory zip content table is much faster than a filesystem stat. As the use of eggs drastically increases the number of entries in sys.path, Python's imports are likely to get slower. However, I am not sure whether our observations for a single large zip (in fact, we use two: one for our application, the other for Python's runtime library) is valid for the case of many small zipped eggs. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
Malthe Borch wrote at 2008-8-29 13:20 +0200: ... Right, so this is basically a question of whether the following template is legal or not: div tal:replace=string:hello world! / In ZPT it would be, because it automatically assumes this namespace declaration: xmlns=http://www.w3.org/1999/xhtml; xmlns:tal=http://xml.zope. org/namespaces/tal xmlns:metal=http://xml.zope.org/namespaces/metal; . This is correct for HTML PageTemplates; XML PageTemplates, too, require the namespace declarations -- at least this has been the case for the former Zope 2 version of PageTemplate (I do not yet know most details about the newer Zope 3 PageTemplate). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Chris Withers wrote at 2008-8-29 10:25 +0100:
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional parameters --
what a simplification and homogenization :-)
Yeah, but since when has simplification or homogenisation been a goal of
Zope 3? ;-)
It was with the Service geddon: make Service and Utility homgogenous.
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] configuration error
Bristow Thankachan wrote at 2008-8-23 15:53 +0530: We are stuck with a configuration error in porting zope2 to python2.5. Can anybody help us in fixing configuration error in the module Zope2. The full log of error message is given below. ... File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 57, in parse section = self.end_section(section, line[2:-1]) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 112, in end_section self.error(e[0]) File /home/zope/ztrunk25/lib/python/ZConfig/cfgparser.py, line 177, in error raise ZConfig.ConfigurationSyntaxError(message, self.url, self.lineno) ConfigurationSyntaxError: invalid warning category: 'Zope2.Startup.tests.test_warnfilter.TestSchemaWarning' (line 8) I can only partially help you. Unfortunately, ZConfig is *VERY* bad with respect to the help it provides to understand the causes of so called configuration problems: It turns all exceptions (configuration problems or else) into ConfigurationErrors and in this process cuts of valuable tracebacks. Thus, we have heavy loss of information that would be helpful to analyse problems occuring during configuration but that are not configuration errors (but some import problems, or incompatibilities with the Python version as in your case). Very bad design in this respect When I meet such a case (ZConfig stupidly tells me about a ConfigurationError which is not (primarily) a configuration error), I temporarily change the ZConfig source: At places try: except : raise ...ConfigurationError(...) I add a raise line before the raise ...ConfigurationError(). By this, I get the original exception and especially the original traceback and then can usually quickly find the original problem. In your special case, some quessing may give a faster result. It is likely that the original problem comes from Zope2.Startup.warnfilter.warn_category. You can put a breakpoint there and then determine by single stepping the cause. An additional guess may give even a faster result. Problably the following lines are to blame: if (not isinstance(cat, types.ClassType) or not issubclass(cat, Warning)): raise ValueError(invalid warning category: %s % `category`) Almost surely, Python made its Warning class a new style class such that isinstance(cat, types.ClassType) fails now. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Chris Withers wrote at 2008-8-19 18:30 +0100: ... class ISomething(Interface): pass ... class MyClass: implements(ISomething) ... m = MyClass() Right, so this does make sense: ISomething(m) __main__.MyClass instance at 0x00BED6E8 This does not: repr(queryAdapter(m,ISomething)) 'None' why the difference? Jim is heavily defending this difference. I am convinced that the difference should not be there but meanwhile have found a use case for it. Suppose, you have a class C that implements I. If queryAdapter would behave like I(...), you would have no way to override the implementation of I by C. With the current behavior, you can use queryAdapter(c, I) to check whether some special requirements apply and in this case use the special purpose adapter. Not that this use case had been able to convince me that the difference were justified. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Jim Fulton wrote at 2008-8-19 17:57 -0400:
While I respect that this feature may have been chosen carefully, it
nevertheless seems more like a misfeature. Chris' expectation was
reasonable and ought not to be violated without a good cause.
queryAdapter is used to look up named adapters. It is also a simpler
version of queryMultiAdapter, which looks up adapters for multiple
objects. In neither of these cases does it make sense to consider the
interfaces already provided by the object being adapted. It makes no
sense to me for queryAdapter to have different semantics depending on
whether the name argument is provided (and is non-blank).
As the implements directive does not specify a name,
one could think that the default name is declared.
Then, your naming argument would go away.
As the I(obj, ...) syntax is more comfortable and more natural than
the get[Multi]Adapter(obj, I, ...), it may even be adequate
to give I(...) an optional name parameter.
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional parameters --
what a simplification and homogenization :-)
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to put , in HTML attributes?
Hermann Himmelbauer wrote at 2008-8-20 19:34 +0200: Hi, I have a page template, that should have the characters and in the resulting HTML code, e.g.: input type=hidden, name=xyz, value=ABC / HTML forbids in attributes: it must be represented there as lt;. Thus, Zope does the correct thing (as standard conformity is a good thing). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
