New-style ExtensionClass
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 -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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)
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
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
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.
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
In article <3F94057B.4020701@zope.com> 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 "<stdin>", line 1, in ? File "<stdin>", line 3, in foo AttributeError: gee a.bar() Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", 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:fg@nuxeo.com
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 "<stdin>", line 1, in ? File "<stdin>", line 3, in foo AttributeError: gee
a.bar()
Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", 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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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
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:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (8)
-
Dieter Maurer -
Florent Guillaume -
Jim Fulton -
Martijn Faassen -
Paul Winkler -
Romain Slootmaekers -
Sidnei da Silva -
Tino Wildenhain