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] Proposal: Align Zope 2 and Zope 3 permissions
Dieter Maurer wrote: 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. Not sure I understand you here. How would I declare that 'set' of an attribute (property) is protected by one permission and 'get' is protected by another? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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?
On Mon, Apr 13, 2009 at 08:14, Dieter Maurer die...@handshake.de wrote: When upgrading from Zope 2.8 to Zope 2.11, I had to fight for several hours because Zope 3 interfaces have been changed: True, you went from Zope 3.0 to 3.3 in one swoop there, and the changes was significant. But most of this changed because the first versions were mistakes. It was after all 3.0. With more experience of using the ZCA changes was needed. The path from 3.0 to 3.3 was mostly done via deprecations, but when you skip two versions, you won't see those. One of the major mistakes with Zope2 is that old ways of doing thing was *never* removed. This makes for both messy internals, and messy product code, as you can use several ways for doing one thing. Zope 3 probably went overboard in it's desire to keep things clean as a result. But you did go from the 2005 version of Zope to the 2008 version of Zope, some upgrade pain is expected. Maybe you have been spoiled by Python and Zope 2 not having much upgrade pain before, bit I honestly don't think it's a good sign for a framework to be so stagnant that three years of development doesn't break somethings. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] regression with Acquisition and __iter__ in Python 2.5 / Zope 2.12
Dieter Maurer wrote: 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: Indeed: class C: ... l=[1,2,3] ... def __getitem__(self, i): ... return self.l[i] list(_) ... from Acquisition import Implicit class C(Implicit): c=C() def __getitem__(self, i): iter(c) iterator object at 0xb7db8ecc list(_) iter(c) [1, 2, 3] list(_) from Acquisition import Implicit iter(c2) list(_) class C(Implicit): ... l=[1,2,3] ... def __getitem__(self, i): ... return self.l[i] ... c=C() iter(c) iterator object at 0xb7dbb38c list(_) [1, 2, 3] c2=C().__of__(c) iter(c2) Traceback (most recent call last): File console, line 1, in module AttributeError: __iter__ cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: 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 The change you are interested in is probably: http://svn.zope.org/Zope/trunk/lib/python/Acquisition/_Acquisition.c?rev=94905r1=92577r2=94905 Acquisition now proxy real iteration via __iter__ correctly (it didn't do that before). What is missing from that change is probably the fallback to the __getitem__ protocol, in case the class isn't a real iterator. Hanno ___ 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?
Am Samstag 11 April 2009 15:05:31 schrieb Hanno Schlichting: Roger Ineichen wrote: Betreff: [Zope-dev] who wants to maintain Zope 3? Is anyone interested in maintaining Zope 3? /me is certainly not With Zope 3 I mean: I think we should take a look if we can build a minimal setup which Plone, Grok and other projects can use. Do you think there could be such a based configuration? Or is there to much difference in each of Plone, Grok, repoze etc? The minimal setup is called Zope Toolkit. None of the mentioned projects is interested in any of the Zope 3 packages, except where those are still tied into the whole. If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. +1, to declaring Zope 3 dead. That should allow us to refactor the remaining packages much more aggressively and reduce the dependencies. -1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain. I personally find it interesting that people are that fast with turning around and killing off things. I personally based my decision for Zope 3 on Philipps book (Web Compontent Development with Zope 3), whereas the latest edition came out just 1 year ago. I adapted the concepts in this book to my needs (e.g. by using z3c-based packages) and it's now a viable way for me and my projects. I understand that people like Zope 2 for historical reasons and Grok for it's simplicity, but I would really wonder that there's no target audience for various ideas/patterns in Zope 3 (security model, ZCML...). I personally heard that repoze.bfg may be the way to go, however, I'm very much in doubt even considering switching, as I wouldn't want to hear 1 year later Let's kill off repoze.bfg. Moreover, I expect that there are many people like me, who started with Zope 3 with Philipp's book, so, would we really want to - ummm - declare them dead? If we do so, to my mind there has to be some migration path to something else, may it be Repoze, or whatever. But just killing off Zope 3 is like saying Sorry guys, you just chose the wrong technology. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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: I've now implemented 1 and 2 on trunk, since they seem pretty non-controversial. 1) Use an event handler to ensure that any permission / declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease. and 2) Emit a warning instead of an error in Five's handler for the class / directive when set_attributes or set_schema are used. I've not done this yet: 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. I'd like to solicit a bit more input before attempting this, as I got at least one -1. I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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?
Hermann Himmelbauer wrote: -1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain. FWIW, I think you're absolutely right. We can't just declare it dead because it is convenient to our goal of having clearer definitions about what we're working with. A piece of open source software is dead if no-one uses it and no-one maintains it. At least then, existing users can't count on bug fixers or security fixes. I think Martijn's point in starting this thread was to try to identify who wants to maintain Zope 3 as an app server and as something that gets released going forward. Let's give those people a chance to respond. Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 Tests: 8 OK
Summary of messages to the zope-tests list. Period Sun Apr 12 12:00:00 2009 UTC to Mon Apr 13 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Apr 12 20:40:43 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011451.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Apr 12 20:42:48 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011452.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Sun Apr 12 20:44:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011453.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sun Apr 12 20:46:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011454.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Sun Apr 12 20:48:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011455.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sun Apr 12 20:50:51 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011456.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sun Apr 12 20:52:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011457.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Sun Apr 12 20:54:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011458.html ___ 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?
Hi Martin -Ursprüngliche Nachricht- Von: zope-dev-bounces+dev=projekt01...@zope.org [mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im Auftrag von Martin Aspeli Gesendet: Montag, 13. April 2009 13:07 An: zope-dev@zope.org Betreff: Re: [Zope-dev] who wants to maintain Zope 3? Hermann Himmelbauer wrote: -1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain. FWIW, I think you're absolutely right. We can't just declare it dead because it is convenient to our goal of having clearer definitions about what we're working with. A piece of open source software is dead if no-one uses it and no-one maintains it. At least then, existing users can't count on bug fixers or security fixes. I think Martijn's point in starting this thread was to try to identify who wants to maintain Zope 3 as an app server and as something that gets released going forward. Let's give those people a chance to respond. Declaring things dead has a tendency to become a self-fulfilling prophecy, and probably not something we should do lightly. This sounds much better then the earlier mails ;-) I'm willing to help to find a way to move the old code parts to a newer and better concept. Note, I don't use this code in my own projects and I don't propose to do that just for fun. But if someone proposes to do it, I'm willing to help. I think we have to support a smooth migration path for the old ZMI views and we can't just skip them. Releasing a Zope 3 app server is another part. I'm not sure if Stephan Richter, he told once, will support it for the future? I still think the Grok, Repoze, Plone, Zope 2 and Zope 3 developer should talk together and find a concept and see how we can find a code base which will fit for each other. This probably only means that we move the zmi part out of the existing zope.* and z3c.* packages. And each project could offer a own management concept and views for the same code base. Regards Roger Ineichen Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 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?
On Mon, Apr 13, 2009 at 12:49, Hermann Himmelbauer du...@qwer.tk wrote: I personally find it interesting that people are that fast with turning around and killing off things. I personally based my decision for Zope 3 on Philipps book (Web Compontent Development with Zope 3), whereas the latest edition came out just 1 year ago. I adapted the concepts in this book to my needs (e.g. by using z3c-based packages) and it's now a viable way for me and my projects. It might be important to point out that this book will continue to be relevant. That book is about ho to develop with the Zope Toolkit, except that it didn't exist when it was written, not even as a concept. Zope 3 was then a monolithic server. It isn't any more. The answer is if somebody wants to maintain the Zope 3 Applictation server, and go on to release a Zope 3.5, 3.6 etc. The libraries will be maintained, and Zope 3 will continue to work for a long time, and bugfixes will happen, even if no releases are done. And we don't need to declare it dead in any way. If nobody steps up to be the next Zope 3 maintainer, then it *is* dead, even if it isn't declared so, and even if we don't want it to be dead. Open source is driven by what people do. If nobody wants to maintain Zope 3, then it will not get any more releases, no matter if we want it to be dead or not. I understand that people like Zope 2 for historical reasons and Grok for it's simplicity, but I would really wonder that there's no target audience for various ideas/patterns in Zope 3 (security model, ZCML...). There is, but those who prefer ZCML over Grok seems to gravitate towards BFG as opposed to Zope 3. Moreover, I expect that there are many people like me, who started with Zope 3 with Philipp's book, so, would we really want to - ummm - declare them dead? It's extremely important to understand the differences between Zope 3, and Zope 3 technologies. The only thing that looks dead is Zope 3 as a big monolithic application server. Few people are interested in that. You seem to be. Hence the question: Who wants to maintain it. Do you? If we do so, to my mind there has to be some migration path to something else, may it be Repoze, or whatever. But just killing off Zope 3 is like saying Sorry guys, you just chose the wrong technology. See, this is the naming problem. You did not chose the wrong technology. You didn't even chose the wrong app server, because there wasn't any choice. Now there is: Zope 3, Grok BFG. All using the same technology. So far you are one of the few having any interest in Zope 3. Up until this thread, nobody showed any interest. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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?
Previously Martin Aspeli wrote: Hermann Himmelbauer wrote: -1 from my standpoint. Two of my projects are fully based on the Zope 3 server, and switching to something else would be quite some pain. FWIW, I think you're absolutely right. We can't just declare it dead because it is convenient to our goal of having clearer definitions about what we're working with. We can effectively not maintain it anymore and stop making release. Which would not be a major change from Zope 3 releases the last few years :) Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] zcml vs. not-zcml (was Re: who wants to maintain Zope 3?)
On 4/13/09 10:33 AM, Lennart Regebro wrote: I understand that people like Zope 2 for historical reasons and Grok for it's simplicity, but I would really wonder that there's no target audience for various ideas/patterns in Zope 3 (security model, ZCML...). There is, but those who prefer ZCML over Grok seems to gravitate towards BFG as opposed to Zope 3. I'll note that you need to write only 1 line of ZCML in BFG to write most BFG applications (the line that tells BFG to scan a package for decorators). BFG is not at all like Zope 3 in this respect. BFG actually uses Grok's martian package to help with the one common case of declaring an adapter (a view adapter). BFG app developers are not really expected to interact with the ZCA via adapter and utility lookups (APIs are provided on top of every other use of the CA by the famework), so essentially you can write most applications in BFG without knowing anything about interfaces, adapters, or the ZCA at all. That said, I'm personally not ZCML-hostile, and as a result I write applications on top of BFG which have lots of ZCML in them. But that's not as a result of the framework; it's an result of how I like to write applications. - C ___ 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?
On Fri, Apr 10, 2009 at 11:33 AM, Martijn Faassen faas...@startifact.com wrote: Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) * 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? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. What I'm *not* talking about is: * maintaining, documenting and installing Grok. * maintaining and documenting any particular Zope Toolkit library (outside of those bits that do ZMI-stuff, those aren't supposed to be in the toolkit) We know people are interested in doing all that. Does Zope Tookit support building a web application out of the box without relying on Grok, Zope 2 or any other framework ? (I am Ok to use a Buildout for building application from Zope Toolkit packages) If the answer to this question is No, then I am interested to maintain the packages necessary to create a simple application out of the box. This is just an academic interest :) Regards, Baiju M ___ 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__
Hanno Schlichting wrote: The change you are interested in is probably: http://svn.zope.org/Zope/trunk/lib/python/Acquisition/_Acquisition.c?rev=94905r1=92577r2=94905 Acquisition now proxy real iteration via __iter__ correctly (it didn't do that before). What is missing from that change is probably the fallback to the __getitem__ protocol, in case the class isn't a real iterator. Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: On Fri, Apr 10, 2009 at 11:33 AM, Martijn Faassen faas...@startifact.com wrote: Hi there, Is anyone interested in maintaining Zope 3? With Zope 3 I mean: * the thing with the ZMI - do you care about the ZMI? * the thing that can be installed as a particular development platform - do you care about the installation story for Zope 3? (as opposed to Grok or your own application's?) * 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? People who are interested in these aspects please speak up, so we can figure out what this all means for the future of Zope 3. If nobody is interested, we should perhaps stop talking about it entirely. If people are just interested in the ZMI, perhaps we should form a ZMI project. What I'm *not* talking about is: * maintaining, documenting and installing Grok. * maintaining and documenting any particular Zope Toolkit library (outside of those bits that do ZMI-stuff, those aren't supposed to be in the toolkit) We know people are interested in doing all that. Does Zope Tookit support building a web application out of the box without relying on Grok, Zope 2 or any other framework ? (I am Ok to use a Buildout for building application from Zope Toolkit packages) If the answer to this question is No, then I am interested to maintain the packages necessary to create a simple application out of the box. This is just an academic interest :) I would say that the answer is no. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ44d0+gerLs4ltQ4RAimzAJ9fm2W/V8R44AjXoa/wEOmVNWBJ6gCePSkc wJudZQswGVm1IL4ntjPrdnQ= =9ZTG -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: I've not done this yet: 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. I'd like to solicit a bit more input before attempting this, as I got at least one -1. I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change. - -1: I think both of those will be true. I also don't see much win. The major goal should be to unify the API for add-ons, rather than the implementation: your #1 and #2 alaready did that, I think. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ44jx+gerLs4ltQ4RAjvwAKCN7uLoypk4eFBDqD6/mC8yW0Sc4ACfTktE YYCdpj8NREIpSXT1Tt7Wsms= =IdzH -END PGP SIGNATURE- ___ 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__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13.04.2009 17:58 Uhr, Chris Withers wrote: Hanno Schlichting wrote: The change you are interested in is probably: http://svn.zope.org/Zope/trunk/lib/python/Acquisition/_Acquisition.c?rev=94905r1=92577r2=94905 Acquisition now proxy real iteration via __iter__ correctly (it didn't do that before). What is missing from that change is probably the fallback to the __getitem__ protocol, in case the class isn't a real iterator. Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in? Since Acquisition is a core module of Zope: the Zope 2 tracker on Launchpad. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknji+wACgkQCJIWIbr9KYxd5ACeO1Sx3ubk9laxtgJsS51w2YRf UJkAnjUV/N52ZAH0KPI1vqZM7MMt0oHD =hk9o -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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] TypeError: ('argument list must be a tuple') when trying load object from old zodb in Zope 2.12.0a1
Hi All,
Any ideas what this means or where it's coming from?
Module ZODB.Connection, line 808, in setstate
Module ZODB.Connection, line 876, in _setstate
Module ZODB.serialize, line 604, in setGhostState
Module ZODB.serialize, line 597, in getState
TypeError: ('argument list must be a tuple', class
'Products.ParsedXML.DOM.Core.Document', None)
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
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__
Andreas Jung wrote: Yes, so this change introduced a bug. Who's the right person to fix it? What's the right collector to report this in? Since Acquisition is a core module of Zope: the Zope 2 tracker on Launchpad. Done: https://bugs.launchpad.net/zope2/+bug/360761 Now, who knows how to fix it? ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: I've not done this yet: 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. I'd like to solicit a bit more input before attempting this, as I got at least one -1. I think this is the bigger win, though, and I'd still like to do it unless performance becomes prohibitive or it turns out to be too invasive a change. - -1: I think both of those will be true. I also don't see much win. The major goal should be to unify the API for add-ons, rather than the implementation: your #1 and #2 alaready did that, I think. I had a deeper look last night, and I think this would be more invasive than I'd feared. I thought originally the Permission class was used everywhere, but on further inspection, I see that manually constructed '_Permission' strings are used in a lot of places, including C code. It frightens me slightly that, having pdb'd my way through AccessControl a number of times, I still have only a fuzzy idea about how the permissions system works, and I haven't found any solid documentation with the code. I think to unify the API, we'd need to: - Promote the zope.security checkPermission method like Hanno suggested - Change rolemap.xml in GenericSetup to accept Zope 2 names - Look at other places where permission names are passed around in code (there are a few places in Plone, for instance) and make sure we always prefer the Zope 3 dotted name. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
