- Zope-Dev - Zope lists

re: DateTime stftime and TAI based timezone is broken or is it?
by Brad Clements 02 Dec '03

02 Dec '03

I think adding right/EST5EDT tzfile info to DateTimeZone.py might solve my problem. Can someone email me the .py script used to create the DateTimeZone.py file? -- Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements

2 2

Help to find URL logs in Zope
by MAHAUT Dany 02 Dec '03

02 Dec '03

Hi, can you give us an explanation in order to trace URL logs in Zope on linux debian ? We'd like to retrieve the percentage of utilization of our different web sites. Best regards, ___________________________________ Dany MAHAUT - Responsable d'Application Groupe EDHEC - Direction des Systèmes d'Information 58, rue du Port 59046 LILLE Tel. +33 (0)3 20 15 45 55 - Fax. +33 (0)3 20 15 45 01 ___________________________________

2 1

Information on ZpdfDocument and Zpdf
by Asad Habib 02 Dec '03

02 Dec '03

Hello. I am looking for extensive documentation on both ZpdfDocument and Zpdf. I checked out www.zope.org but did not find anything substantial on these products. Your help would be greatly appreciated. Thanks. -Asad __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

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