Python 2.0 and Zope Status?
What's the current state of Zope with Python 2.0? My current understanding of the issues is: - Problem with ExtensionClasses and 2.0's circular reference GC. Can someone elaborate on this? Is configuring python2.0 with the --without-cycle-gc flag a sufficient workaround for now? - Python 2.0's cPickle and cStringIO should be used instead of the Zope-supplied versions. Is that it? Anything else I'm missing? Thanks.
On 20 Oct 2000 19:09:47 GMT, tsarna@endicor.com (Ty Sarna) wrote:
What's the current state of Zope with Python 2.0? My current understanding of the issues is:
- Problem with ExtensionClasses and 2.0's circular reference GC. Can someone elaborate on this? Is configuring python2.0 with
That used to be a problem with some early cvs release, but it seems to have gone away now. Note that ExtensionClasses do not yet participate in the gc machinery, so cycles involving them can still not be collected.
the --without-cycle-gc flag a sufficient workaround for now?
I suggest this is the first thing you try if python faults during startup.
- Python 2.0's cPickle and cStringIO should be used instead of the Zope-supplied versions.
Yes.
Is that it? Anything else I'm missing?
There are several places where Zope is not defending against objects which raise an exception inside str(). This has not been a problem up to now, but 2.0's unicode objects expose the problem. The most serious possible effect is of terminating a publisher thread. Fixes for these bugs are bundled into my patches to support Unicode, at http://www.zope.org/Members/htrd/wstring Other than that, 2.0 is great. Ive been using it extensively for several months now without problem. Toby Dickenson tdickenson@geminidataloggers.com
In article <8us7vs0s2jcai9elsod3otupjishhds5kq@4ax.com>, Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
- Problem with ExtensionClasses and 2.0's circular reference GC. Can someone elaborate on this? Is configuring python2.0 with
That used to be a problem with some early cvs release, but it seems to have gone away now.
Yep... I tried it before you replied and it seems to work just fine.
Note that ExtensionClasses do not yet participate in the gc machinery, so cycles involving them can still not be collected.
However, Zope code should be fine because that's always been the case :)
There are several places where Zope is not defending against objects which raise an exception inside str(). This has not been a problem up to now, but 2.0's unicode objects expose the problem.
But again, not something that should effect existing code (which should never generate unicode objects)
Is there an unique object ID in the ZODB that remains constant in all times through out the life time of the ZODB? And if so, where is it created and how do I access it? In other word how do I use it?
I can vaguely recall seeing something called OID.
You can (from python) access the _p_oid attribute of an object to get it's OID, but not all that useful. Given an oid, there's no way to get back to a useful object. I've thought about patching _setObject to store a "hard" parent pointer, thus making it possible to walk back up the tree and figure out how to create a properly wrapped version of the object as it it had been accessed via it's canonical path. There are complications like mountable storages though.
Unfortunately there are a lot of things that Zope just can't do because there is no way to get a persistent "ticket" for an object that can be handed out to some external system, and then later redeemed for the (properly wrapped) object. Pathnames are not useful, because they don't last for the object's lifetime.
I haven't tried it, but I'm almost positive the semantics of ZServer's FTP are a bit wonky because of this. For some other things I'd like to do, it's a fatal blow.
Thanks Ty, It really works for what I intend to do (at the moment anyway).
I need it to track discussions related to an object, but stored in a SQL-database. I been pondering a traversal interface in the "commentable" objects, that would give the illusion that the discussion items really are object agregated in the "commentable".
I also guess this could be something ZPatterns could solve in the future?
For this type of use, ZPatterns can easily solve the problem.
One way to do this: Make your objects DataSkins-derived, and set up SkinScript rules so that when the sql_key property is accessed, a new key is generated and the object's sql_key is set to it. Now, anytime you ask for object.sql_key, you either get one it was assigned previously (the SkinScript attribute providers are only used if a persistent attribute can't be found) or a new one is generated and stored in the (persistent) object for future use.
Now you can write other SkinScript that keys off of self.sql_key to provide access and storage of whatever other attributes from/to SQL.
I was think more in the line of ObjectAttributes aggregated in a DataPlugin (which in it's turn could use a RDBS for persistent storage). The reason why I really want this is for letting write intensive persistent objects. I'm not sure if this solve the problem but it one idea I been thinking about. Regards, Johan Carlsson
participants (3)
-
Johan Carlsson -
Toby Dickenson -
tsarna＠endicor.com