Re: [Zope-dev] New-style ExtensionClass , maybe stupid question...
Yo, this maybe a stupid question, and totally off topic, but ... will the new type extension class avoid the problems related with mixin classes not extending ExtensionClass.Base? (for explanation and workaround see the thread http://mail.zope.org/pipermail/zope/2002-June/116094.html ) Romain Slootmaekers. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Dieter Maurer schrieb: Jim Fulton wrote at 2003-10-20 11:55 -0400: > ... > Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 > should be a release that provides *only*: > > - New-style ExtensionClass, and > > - ZODB 3.3, featuring multi-version concurrency control, > > plus any features that have been added to the head since the Zope 2.7 > branch was created. > > This idea is pretty appealing to me. I wonder what others think of it. +1 +10 Tino ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Dieter Maurer wrote: Jim Fulton wrote at 2003-11-22 12:14 -0500: > ... > Also note that I had to get rid of the validateValue call. It's important > that we always pass the name and container to code that needs to get roles. We need "name" and "container" only for objects that do not have their own "__roles__" attribute. This essientially means for the newly implemented methods. But, for bound methods, we can determine name and container from the objects. We can determine the container, but we can't reliably the name: >>> class Foo: ...def eeek(self): pass ...oook = eeek >>> Foo().oook.__name__ 'eeek' I would therefore keep "validateValue" and try to determine container and name. No can do. I'll note that validateValue is hardly every used, at least in the Zope CVS. We really *do* need to refactor this stuff. What we're doing now is a stop-gap measure. Before releasing 2.8, I want to try to design what we want in 2.9 and have 2.8 include warnings and other guidence that will help people get ready for 2.9. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Jim Fulton wrote at 2003-11-22 12:14 -0500: > ... > Also note that I had to get rid of the validateValue call. It's important > that we always pass the name and container to code that needs to get roles. We need "name" and "container" only for objects that do not have their own "__roles__" attribute. This essientially means for the newly implemented methods. But, for bound methods, we can determine name and container from the objects. I would therefore keep "validateValue" and try to determine container and name. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Dieter Maurer wrote: Dieter Maurer wrote > ... protecting simple type attributes by roles ... > > Patch attached. I have a small optimization: if ( # start with inexpensive checks roles is not _noroles or name is None or value is None or container is None # now the expensive ones or hasattr(value,'__roles__') or not hasattr(aq_base(container), name + '__roles__') ): If we replace "hasattr(value,'__roles__')" above by "hasattr(aq_base(value),'__roles__')", then the (discarded) roles computation becomes a bit cheaper. I'm going with a bit simpler approach See my upcoming checkin. Basically, I've created a getRoles method to be used instead of "getattr(ob, '__roles__', _noroles)". One issue is that the security polict is not the only place where this special computation needs to be done. Also note that I had to get rid of the validateValue call. It's important that we always pass the name and container to code that needs to get roles. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Dieter Maurer wrote > ... protecting simple type attributes by roles ... > > Patch attached. I have a small optimization: if ( # start with inexpensive checks roles is not _noroles or name is None or value is None or container is None # now the expensive ones or hasattr(value,'__roles__') or not hasattr(aq_base(container), name + '__roles__') ): If we replace "hasattr(value,'__roles__')" above by "hasattr(aq_base(value),'__roles__')", then the (discarded) roles computation becomes a bit cheaper. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Dieter Maurer wrote:
Jim Fulton wrote at 2003-11-13 15:22 -0500:
> ...
>We need to refactor the way security assertions (permission
>settings) are stored and accessed. We need to store required
>permissions (__permissions__) on objects. When we need to figure
>out roles, we need to compute them at a higher level. (For
>example, we could compute the needed roles in the zope security
>policy It's likely that we can speed security checks when doing
>this.)
>
> I estimate that the necessary refactoring would take me 3-5
> days. The vast majority of the required time will be spent writing
> tests. I really need to focus on Zope 3 for a while, so I may not
> be able to get back to this soon. I think that this is an area
> where some volunteers could make a big difference. I'd be happy to
> work with some folks on this.
Folklore says that Zope cannot protect attributes of simple types
(because they do not provide the method magic that will be lost
for NSEC).
From your patch, I think you are talking about protection of
attributes of non-simple types whose values are not simple types.
That is, protecting the title attribute of a folder even though the
value of the attribute is a string and thus, can't be assigned a
__roles__ attribute.
However, whenever I looked at ZopeSecurityPolicy (and I did often),
I could not believe that this is true. I always thought, it would
be easy to provide security declarations for simple type attributes, too.
Of course, Zope cannot check a bare value of simple type, but
usually it has "container" and/or "parent" and then checking would
be easy by looking at related ("__roles__") attributes of the container/parent.
I will see this weekend whether I have been true.
If so, the same mechanism could (in principle) be used for
methods.
Bound methods can even be checked without "container/parent"
as they allow access to the bound instance.
And a day later, Dieter Maurer wrote:
> Patch attached.
So, when we are accessing a named attribute and the value doesn't
have security data, look for security data on the object we got it
from. I like the general idea.
Hm, I suppose that this would let us keep the __roles__ travesty for now,
which would allow us to proceed with 2.8 without doing the refactoring now.
Very nice. (well, sort of ;)
I'll see if this idea lets me get the "devil branch" merged to the trunk next
week. (I need to make the next Z3 milestone release first.)
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Dieter Maurer wrote at 2003-11-14 20:43 +0100:
> Jim Fulton wrote at 2003-11-13 15:22 -0500:
> > ... new security policy for NSEC ...
> Folklore says that Zope cannot protect attributes of simple types
> (because they do not provide the method magic that will be lost
> for NSEC).
> ...
> Of course, Zope cannot check a bare value of simple type, but
> usually it has "container" and/or "parent" and then checking would
> be easy by looking at related ("__roles__") attributes of the container/parent.
>
> I will see this weekend whether I have been true.
> If so, the same mechanism could (in principle) be used for
> methods.
Patch attached.
--
Dieter
--- AccessControl/ZopeSecurityPolicy.py~ 2003-06-10 09:08:49.0 +0200
+++ AccessControl/ZopeSecurityPolicy.py 2003-11-15 12:41:28.0 +0100
@@ -211,3 +211,42 @@
if type(roles) is StringType:
roles=[roles]
return context.user.allowed(object, roles)
+
+
+###
+# DM: experimental (proof of concept) implementation of explicite
+# protection for simple type attributes
+# Attribute "a" is protected by roles "a__roles__" in its container
+if os.environ.get("ZOPE_SECURITY_PROTECT_ATTRIBUTES"):
+
+from Acquisition import aq_base
+
+class ZopeSecurityPolicy(ZopeSecurityPolicy):
+
+_inherited_validate = ZopeSecurityPolicy.validate
+
+def validate(self, accessed, container, name, value, context,
+ roles=_noroles, None=None,
+ ):
+# check whether the standard security policy can/must decide
+if (
+# start with inexpensive checks
+roles is not _noroles
+or name is None
+or value is None
+or container is None
+# now the expensive ones
+or hasattr(value,'__roles__')
+or not hasattr(aq_base(container), name + '__roles__')
+):
+# let standard security policy decide
+pass
+else:
+# the container provides roles for access to this value
+roles = getattr(container, name + '__roles__')
+# pretend, we access the container (what we are doing indeed)
+value = container
+
+return self._inherited_validate(accessed,container,
+name,value,
+context,roles)
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Jim Fulton wrote at 2003-11-13 15:22 -0500:
> ...
>We need to refactor the way security assertions (permission
>settings) are stored and accessed. We need to store required
>permissions (__permissions__) on objects. When we need to figure
>out roles, we need to compute them at a higher level. (For
>example, we could compute the needed roles in the zope security
>policy It's likely that we can speed security checks when doing
>this.)
>
> I estimate that the necessary refactoring would take me 3-5
> days. The vast majority of the required time will be spent writing
> tests. I really need to focus on Zope 3 for a while, so I may not
> be able to get back to this soon. I think that this is an area
> where some volunteers could make a big difference. I'd be happy to
> work with some folks on this.
Folklore says that Zope cannot protect attributes of simple types
(because they do not provide the method magic that will be lost
for NSEC).
However, whenever I looked at ZopeSecurityPolicy (and I did often),
I could not believe that this is true. I always thought, it would
be easy to provide security declarations for simple type attributes, too.
Of course, Zope cannot check a bare value of simple type, but
usually it has "container" and/or "parent" and then checking would
be easy by looking at related ("__roles__") attributes of the container/parent.
I will see this weekend whether I have been true.
If so, the same mechanism could (in principle) be used for
methods.
Bound methods can even be checked without "container/parent"
as they allow access to the bound instance.
--
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
On Thu, Nov 13, 2003 at 04:35:52PM -0500, Jim Fulton wrote: | The expectation is that existing Zope 2 products will work with 2.8. | The security APIs will be unchanged. Great. | > In case that was the case, would porting the zcml machinery | >and the security policy from zope3 completely out of question? | | We want Zope 2.8 to happen as soon as possible, so we can start working | on Zope 2.9. Zope 2.9 will be the release that incorprates major parts | of Zope 3. | | We think that NSEC and ZODB 3.3 provide more than enough of a change for | one release. :) Agreed. It didn't hurt for asking though :) | > This is something I would really love to see in zope2. | | Me too. We need to get 2.7 and 2.8 out the door as soon as we | can so we can get working on 2.9. Yay! I can hardly wait for that one! -- Sidnei da Silva <[EMAIL PROTECTED]> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher From: Ean Schuessler <[EMAIL PROTECTED]> The unrecognized minister of propaganda, E -- Debian, joking ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
| Gory details | | I estimate that the necessary refactoring would take me 3-5 | days. The vast majority of the required time will be spent writing | tests. I really need to focus on Zope 3 for a while, so I may not | be able to get back to this soon. I think that this is an area | where some volunteers could make a big difference. I'd be happy to | work with some folks on this. You didn't mention if this would have any impact on existing products. In case that was the case, would porting the zcml machinery and the security policy from zope3 completely out of question? This is something I would really love to see in zope2. -- Sidnei da Silva <[EMAIL PROTECTED]> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Avoid the Gates of Hell. Use Linux -- unknown source ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass, ZODB 3.3, and Zope 2.8 status
Sidnei da Silva wrote: | Gory details | | I estimate that the necessary refactoring would take me 3-5 | days. The vast majority of the required time will be spent writing | tests. I really need to focus on Zope 3 for a while, so I may not | be able to get back to this soon. I think that this is an area | where some volunteers could make a big difference. I'd be happy to | work with some folks on this. You didn't mention if this would have any impact on existing products. The expectation is that existing Zope 2 products will work with 2.8. The security APIs will be unchanged. > In case that was the case, would porting the zcml machinery and the security policy from zope3 completely out of question? We want Zope 2.8 to happen as soon as possible, so we can start working on Zope 2.9. Zope 2.9 will be the release that incorprates major parts of Zope 3. We think that NSEC and ZODB 3.3 provide more than enough of a change for one release. :) > This is something I would really love to see in zope2. Me too. We need to get 2.7 and 2.8 out the door as soon as we can so we can get working on 2.9. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Martijn Faassen wrote: Jim Fulton wrote: See: Packages3/Interface in CVS If you put this ahead of the Zope 2 Interface package in your Python path, then you can use Zope 3 interfaces with Zope 2. That's great news! Is it the intention that this will be the default Interface package in Zope 2.8 then, Or 2.9. > or is there a reason to keep on supporting the old interface package? It's a matter of time. We may not have time to replace the interface package for 2.8. Then again, I'm sure we could find volunteers to help with that. Jim P.S. It sure would be great to get 2.7 out. :) If anyone can help with that (who isn't already helping, of course), please get with Brian Lloyd. -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Jim Fulton wrote: > See: > > Packages3/Interface in CVS > > If you put this ahead of the Zope 2 Interface package in > your Python path, then you can use Zope 3 interfaces with Zope 2. That's great news! Is it the intention that this will be the default Interface package in Zope 2.8 then, or is there a reason to keep on supporting the old interface package? Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Martijn Faassen wrote: Hey, Belated response, but.. Jim Fulton wrote: Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 should be a release that provides *only*: - New-style ExtensionClass, and - ZODB 3.3, featuring multi-version concurrency control, plus any features that have been added to the head since the Zope 2.7 branch was created. If this hasn't been added to the head yet, being able to use Zope 3 interfaces on Zope 2 objects would be nice. Right now Zope barfs over any class that gets registered that uses Zope 3 interfaces. That way the Zope 3 interfaces and component architecture packages can be used from Zope 2, at least to a certain extent. One fairly simple way around that is to modify Zope 3 interfaces so they don't use __implements__ but something else (I used __implements2__) but that could be seen as a hack. It is clean in the sense that Zope 2 won't trip over Zope 3 and vice versa. But perhaps there's another approach which actually modifies the Zope 2 core. See: Packages3/Interface in CVS If you put this ahead of the Zope 2 Interface package in your Python path, then you can use Zope 3 interfaces with Zope 2. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Hey, Belated response, but.. Jim Fulton wrote: > Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 > should be a release that provides *only*: > > - New-style ExtensionClass, and > > - ZODB 3.3, featuring multi-version concurrency control, > > plus any features that have been added to the head since the Zope 2.7 > branch was created. If this hasn't been added to the head yet, being able to use Zope 3 interfaces on Zope 2 objects would be nice. Right now Zope barfs over any class that gets registered that uses Zope 3 interfaces. That way the Zope 3 interfaces and component architecture packages can be used from Zope 2, at least to a certain extent. One fairly simple way around that is to modify Zope 3 interfaces so they don't use __implements__ but something else (I used __implements2__) but that could be seen as a hack. It is clean in the sense that Zope 2 won't trip over Zope 3 and vice versa. But perhaps there's another approach which actually modifies the Zope 2 core. > This idea is pretty appealing to me. I wonder what others think of it. If it also has the interfaces matter sorted out and it causes this to be released more quickly, then by all means. It's easy enough for me to include other parts of the Zope 3 source tree. Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Florent Guillaume wrote: ... Excellent. Will it also fix this particularity of ExtensionClass: from ExtensionClass import Base ... class A(Base): ... def foo(self): ... self.gee ... def bar(self): ... del self.gee ... a=A() a.foo() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in foo AttributeError: gee a.bar() Traceback (most recent call last): File "", line 1, in ? File "", line 5, in bar KeyError: gee I.e., the fact that KeyError is raised whereas a normal class would raise AttributeError. ... Jim makes a unit test ... Yes. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
In article <[EMAIL PROTECTED]> you write: > > I've started work on a new-style ExtensionClass. This is a port > of ExtensionClass to new-style classes. This will provide a number > of advantages: > > - Use of new-style class features (e.g. descriptors) in Zope objects. > > - Support for cyclic garbage collection. > > - Ability to use new-style classes as base classes of Zope objects. > > - Use of a version of ZODB that supports non-ExtensionClass classes. > > - Pave the way for sharing code between Zope 2 and Zope 3. > > I hope I can merge this into the Zope 2 head in a week or two. > > This is a rather deep change and it is likely to cause some instability > on the CVS head for a while. I'm doing this now, rather than later, > to give us plenty of time to find and fix problems before a Zope 2.8 > release. > > Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 > should be a release that provides *only*: > > - New-style ExtensionClass, and > > - ZODB 3.3, featuring multi-version concurrency control, > > plus any features that have been added to the head since the Zope 2.7 > branch was created. > > This idea is pretty appealing to me. I wonder what others think of it. > > Jim Excellent. Will it also fix this particularity of ExtensionClass: >>> from ExtensionClass import Base ... class A(Base): ... def foo(self): ... self.gee ... def bar(self): ... del self.gee ... >>> a=A() >>> a.foo() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in foo AttributeError: gee >>> a.bar() Traceback (most recent call last): File "", line 1, in ? File "", line 5, in bar KeyError: gee I.e., the fact that KeyError is raised whereas a normal class would raise AttributeError. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
On segunda-feira, out 20, 2003, at 13:55 Brazil/East, Jim Fulton wrote: Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 should be a release that provides *only*: - New-style ExtensionClass, and - ZODB 3.3, featuring multi-version concurrency control, plus any features that have been added to the head since the Zope 2.7 branch was created. This idea is pretty appealing to me. I wonder what others think of it. I would kill for having that. +1. ~dc ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Jim Fulton wrote at 2003-10-20 11:55 -0400: > ... > Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 > should be a release that provides *only*: > > - New-style ExtensionClass, and > > - ZODB 3.3, featuring multi-version concurrency control, > > plus any features that have been added to the head since the Zope 2.7 > branch was created. > > This idea is pretty appealing to me. I wonder what others think of it. +1 Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
On Mon, Oct 20, 2003 at 11:55:39AM -0400, Jim Fulton wrote: > > I've started work on a new-style ExtensionClass. This is a port > of ExtensionClass to new-style classes. This will provide a number > of advantages: > > - Use of new-style class features (e.g. descriptors) in Zope objects. woohoo! this all sounds great. One question about new-style ExtensionClass... I wonder if it will address a minor gripe I have with the current ExtensionClass. I spent a few minutes yesterday debugging some code like this: class FooProduct(SimpleItem): def broken(self, obj): if isintance(obj, FooProduct): # never true! raise TypeError def working(self, obj): if obj.meta_type == FooProduct.meta_type: raise TypeError As it turns out, isinstance(FooProduct(), FooProduct) returns false! AFAICT it's ExtensionClass that is responsible for this surprising behavior. The meta_type approach is a decent workaround, but it means I can't automatically detect all subclasses of FooProduct, which is a nice feature of isinstance. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MARTIAN TAB GEOLOGIST! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
