Zope-Dev November 2003

zope-dev@zope.dev

51 participants
52 discussions

relations in objects
by Jason Corbett 28 Dec '03

28 Dec '03

Hello Zope developers, I'm a newbie (sorry most people have this curse at one point or another). I have read the zope book (or at least most of it), and the zope developer manual. I can't quite figure out how to have relationships between instances of classes in the database. Let me first ask if I'm using zope for the correct thing. I see that a lot of zope products deal with content management, while mine doesn't really. Basically I want to do what I would normally do with mysql and php, but use zope instead. So I need a way to reference in some intelligent way between objects in zope, and I need a way to query for a list of them. I read about ZCatalogs, etc and how you can use that for querying and indexing. That isn't my first priority, so I'll worry about that a little later. Basically I have an instance of a class 'A'. As part of it I need to reference either a single or in some cases multiple instances of class 'B'. Basically I'll have a mix of one-to-one relations and one-to-many. When I'm coding my python class (I'm going to do a product if you can't tell), how would I get a list of the 'B' instances that relate to this object, and how would I store that? The zope developer manual was pretty good for writing classes, and making views on it, but I need to be able to call methods on those instances and return lists of them. Sorry for the long email, I just don't want to leave details out. If you think I'm barking up the wrong tree, and shouldn't be using zope for this, don't be afraid to let me know. Although I will be pretty disappointed, I think zope is exactly what I've been looking for, I can't find anything like it in any other language. Jason Corbett __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

7 10

Heads up: about to merge new-style ExtensionClass and ZODB 3.3 into Zope 2 head
by Jim Fulton 10 Dec '03

10 Dec '03

Hi, I'm just about to start writing the checkin logs for the merge of new-style ExtensionClass and ZODB 3.3 into the Zope 3 head. I expect the merge to be done within the next hour or two. Except for a test failure and some warnings pre-existing on the head, all of the tests and Zope runs. This is a huge change though and I expect this to be the beginning of a period of relative instability. Hoepfully, we can all work together to quickly address whatever problems come up. As I mentioned in another message, old Zope 2 databases won't work on the head for a while until I have a chance to come up with a mechanism for converting ancient BTrees and intSets. Unfortunately, until a change I checked into the Zope 2.7 branch on Wednesday, Zope was continuing to use the old depricated BTrees for a key data structure. 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

6 11

New-style ExtensionClass
by Jim Fulton 02 Dec '03

02 Dec '03

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

8 11

New-style ExtensionClasses (Zope 2.8) -- MRO issue
by Jim Fulton 29 Nov '03

29 Nov '03

I've been working on a "new-style" ExtensionClass (nsEC) project to reimplement ExtensionClass as a new-style meta class. This will allow ExtensionClasses (i.e. most Zope 2 classes) to be able to use features of new-style Python classes, including: - New protocols, - Descriptors, - Garbage Collection, ... I think I've got this largely working, but have encountered a significant issue that I'd like some input on. New-style classes and classic classes use different algorithms for looking up inherited attributes (e.g. methods). Classic classes use a left-to-right depth-first algorithm. Python 2.3 uses a "C3 Method-Resolution Order" algorithm. I won't try to explain how this algorithm works. If you are curious, see: http://www.python.org/2.3/mro.html This new algorithm has a couple of noteworthy properties: - It yields different lookup results than the left-to-right depth-first algorithm used for classic classes. - It is sometimes impossible to compute a "method resolution order" for a given class and base classes. >>> class A(object): ... pass >>> class B(A): ... pass >>> class C(A, B): ... pass Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: Cannot create a consistent method resolution order (MRO) for bases B, A The original ExtensionClass used the left-to-right depth-first algorithm used for classic classes. Currently, nsEC inherits the new method lookup algorithm from type (the standard Python 2.3 metaclass used for new-style classes). This has run into significant difficulties with the Zope 2 classes, which have a highly complex inheritence graph. An initial analysis showed that for more than half of the classes in Zope 2, it was impossible to compute a method-resolution order using the new algorithm. After about a day of analysis (and development of a tool to aid in the analysis) I've been able to adjust the Zope classes so that they will work with the new algorithm. I also analyzed the CMF head. To use the new algorithm with the CMF, it was necessary to make some changes to the CMF and to Zope. In one case, it was necessary to copy some methods around. An interesting result of the analysis is that it identified several methods that were being inherited incorrectly. The new inheritence algorithm yeilded better results for these cases, once the classes were modified enough to use the algorithm at all. It is very likely that, if we use the new algorithm for nsEC, many products will not work anymore (meaning with Zope 2.8). Modifying the products to work will probably be a non-trivial undertaking. We have three alternatives: 1. Use the old method-lookup algorithm for nsEC. Pro: backward compatible Con: may produce odd results if a new-style class with a complex arrangement of base classes is mixed with an ExtensionClass. 2. Use the new-style method-lookup algithm Pro: Most consistent with new-style classes. Cons: Likely that many products will be broken and require change to work with nsEC/Zope 2.8. Analysis of the changes needed to fix method-resolution-order problems is extremely complex. 3. Use a hybrid schema. I'll call this the "encapsulated base" scheme. Consider: >>> class C(X, Y, Z): ... def foo(self): ... ... ... When we look up an attribute, we do the following: - Look in C's dictionary first. All three algorithms agree on this. :) - Look up the attribute in X. We don't care how we het the attribute from X. If X is a new-style-class, we use the new algithm. If X is a classic class, we use left-to-right depth-first. If X is an nsEC, use the "encapsulated base" algithm. If we don't find the attribute in X, look in Y and then in Z, using the same approach. This algithm will produce backward compatible results, providing the equivalent of left-to-right depth-first for nsECs and classic classes. (Note for the more advanced reader: we'll actually do something less abstract. We'll use a simple algorthm to merge the __mro__ of the base classes, computing an __mro__ for classes classes using the left-to-right depth-first algorithm. We'll basically lay the mros end-to-end left-to-right and remove repeats, keeping the first occurence of each class.) I find this approach appealing for reasons of encapsulation. When reasoning about C, I can reason from known behavior of X, Y, and Z, without considering their respective inherietnce hierarchies, which I consider to be an implementation detail. Pros: backward compatible Less likely than option 1 to produce odd results if a new-style class with a complex arrangement of base classes is mixed with an ExtensionClass. Con: may produce odd results if a new-style class with a complex arrangement of base classes is mixed with an ExtensionClass. Thoughts? I am worried enough about breaking products that I'm inclined to go with option 3. Does anybody think we ought to use the new algorithm (option 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

11 28

Can we forsake database backward compatability on the head for a while?
by Jim Fulton 28 Nov '03

28 Nov '03

Zope 2.8 will not include the old BTree or intSet objects. I plan to arrange for this not to be a problem for old databases. Somehow, Zope 2.8 will convert these automatically. I haven't done this yet though. I'd like to merge the new-style ExtensionClass and ZODB 3.3 work soon. I'd like not to wait for the old-style BTree and intSet compatability work. This would mean that old databases would not be useable with the CVS head in the near term. Would this cause anyone any problems? 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

1 1

session concurrency
by Santi Camps 28 Nov '03

28 Nov '03

Hi all, I've a product, http://zetadb.sourceforge.net, that uses SESSION extensively. I've just discover, unhappiness, that there are some problems when SESSION object is changed at the same time in two diferent python scripts (using frames). The two frames are changing diferent keys of the SESSION object, but at the end the whole SESSION object is saved, I think, so one of the two objects losses its SESSION data Anybody knows any workarround about this? Thanks in advance Santi Camps

4 8

typo fix
by J. Cameron Cooper 26 Nov '03

26 Nov '03

Here's a super-quick "bug" fix for someone with a Zope development tree. I'm currently trying to decide how one might turn a directive. Zope/skel/etc/zope.conf < # If this directive is turned, Zope performs 'product installation' > # If this directive is turned on, Zope performs 'product installation' --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."

2 1

Zope3 Product Sprint
by Arndt Droullier 26 Nov '03

26 Nov '03

Zope3 Product Sprint: --------------------- The sprint will take place from Dec. 4th to 7th (Thursday through Sunday) at the University of Applied Sciences of Duesseldorf (Fachhochschule Duesseldorf), Germany. This sprint aims at porting Zope2 products to Zope3 as well as creating new cool Zope3 products. Take a look at the official site for further information English: http://www.dzug.org/regional/rzug/ENGLISHSite German: http://www.dzug.org/regional/rzug/RheinlandProductsSprint

1 0

Zope 2.7 b3 problem with reindexing catalog
by robert 25 Nov '03

25 Nov '03

If I try to reindex a (plone) portal_catalog I get the following error Traceback (innermost last): * Module ZPublisher.Publish, line 100, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Products.ZCatalog.ZCatalog, line 474, in manage_reindexIndex * Module Products.ZCatalog.ZCatalog, line 459, in reindexIndex TypeError: catalog_object() got an unexpected keyword argument 'update_metadata' Display traceback as text -- mit freundlichen Grüssen Robert Rottermann www.redCOR.ch

6 12

permissions on a python script...
by scripts-urban＠imeme.net 24 Nov '03

24 Nov '03

when I call my form processing script from a form action zope prompt me for a password I have fiddled with both the owner and security settings, with no success Any and all advice welcomed -thanks again -josh

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev November 2003