- Zope-Dev - Zope lists

Zope Tests: 5 OK
by Zope Tests Summarizer 25 Jul '08

25 Jul '08

Summary of messages to the zope-tests list. Period Thu Jul 24 11:00:00 2008 UTC to Fri Jul 25 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Jul 24 21:05:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009905.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 24 21:07:01 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009906.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 24 21:08:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009907.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 24 21:10:01 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009908.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 24 21:11:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009909.html

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 24 Jul '08

24 Jul '08

Summary of messages to the zope-tests list. Period Wed Jul 23 11:00:00 2008 UTC to Thu Jul 24 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Jul 23 21:00:46 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009900.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 23 21:02:16 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009901.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 23 21:03:46 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009902.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 23 21:05:16 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009903.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Jul 23 21:06:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009904.html

1 0

Deprecation Warning
by vyshakh krishnan 23 Jul '08

23 Jul '08

Hello everyone, Since the deprecation warning is due to the conversion of error_type into string by 'raise_standardErrorMessage' method, is it still necessary to use new user defined Exception class or do we want to modify the function 'raise_standardErrorMessage' .

3 2

Utility factory handling for zope.component
by Wichert Akkerman 23 Jul '08

23 Jul '08

Tools like GenericSetup which deal with mangement of utility registration are a bit handicapped at the moment: even though you can register a utility using a factory the utility registration itself only runs the factory methods but does not keep any information on it. As a result you can not round-trip utility registration information or check if the current configuration has changed from an original configuration. To fix that I made a wichert-utility-factories branch of zope.component which adds the factory information to the utility registration. All changes are fully backbwards compatible at both the API and persistence level. If there are no objections I intend to merge the branch to trunk in a few days. Wichert. -- Wichert Akkerman <wichert(a)wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.

4 5

Deprecation Warning
by vyshakh krishnan 23 Jul '08

23 Jul '08

Hi everybody, While porting Zope2 on Python2.5, I am now trying to remove the deprecation warnings.Most of them are due to the raising of string exceptions. One of such warnings in the module Products is /home/zope/ztrunk25/lib/python/OFS/SimpleItem.py:248: DeprecationWarning: raising a string exception is deprecated raise error_type, v, tb These warnings can be removed by changing these string exceptions to class based exceptions. Can anyone suggest how these changes can be made? With regards Vyshakh

3 2

Zope Tests: 5 OK
by Zope Tests Summarizer 23 Jul '08

23 Jul '08

Summary of messages to the zope-tests list. Period Tue Jul 22 11:00:00 2008 UTC to Wed Jul 23 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Jul 22 21:03:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009895.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:04:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009896.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:06:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009897.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:07:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009898.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:09:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009899.html

1 0

Ordering of fields with schema interface subclassing
by Martin Aspeli 22 Jul '08

22 Jul '08

Hi, Suppose I have an interface IDerived that's derived from an interface IBase, overriding a field from it. >>> from zope.interface import Interface >>> from zope.schema import TextLine >>> class IBase(Interface): ... a = TextLine(title=u"a") ... b = TextLine(title=u"b") ... c = TextLine(title=u"c") >>> class IDerived(IBase): ... b = TextLine(title=u"b", default=u"B") In this case, the field ordering of zope.schema means that I'll get something like this: >>> from zope.schema import getFieldNamesInOrder >>> getFieldNamesInOrder(IDerived) ['a', 'c', 'b'] I had rather expected the order to be ['a', 'b', 'c']. That is, I would expect a field that overrides a field from a base interface, to retain the base interface's order. One way to fix this is to do: >>> IDerived['b'].order = IBase['b'].order Now both will have the same order, of course. So, I'm wondering: - Is it harmful to have two fields with the same order like this when they share a name? - Should this be the default behavior when deriving interfaces from one another like this? If the latter is desirable, I'd be willing to help find a way to implement it. The field order is just an ever-increasing int that's set in Field.__init__(), so we'd probably need some after-the-fact fixing up of fields. One way to do that would be to fire an event at the end of InterfaceClass.__init__() and have an event handler to fix the order, though that'd make zope.interface dependent on zope.event which is probably not desirable. We could simulate the event handler in another way, of course, e.g. by having the interface initialiser loop over its attributes and see if they support e.g. an IOrderAware interface and call a method on it, and have Field implement this. What do you think? Martin

2 2

Re: SVN: grokcore.view/trunk/ With the new grokcore.component 1.5, we can simply say
by Tres Seaver 22 Jul '08

22 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Log message for revision 88701: > With the new grokcore.component 1.5, we can simply say > > from grokcore.component import * > > and only get the actual public API imported into the local namespace. Please don't encourage the 'import *' coding style anywhere: it makes finding the source of a token nearly impossible. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhjxe+gerLs4ltQ4RAvviAKCGC3Lg5HEfOBOExZpoGZNEwhpucwCgwJnt 4uLRLxTPv/sHINd2Et55zPY= =h6lf -----END PGP SIGNATURE-----

1 0

BdbQuit and the testrunner
by Fred Drake 22 Jul '08

22 Jul '08

I often find that I debug problems by inserting a pdb.set_trace() in code, and then quitting the debugger with "q" once I've gathered information I need to make code changes. This causes a BdbQuit exception to be raised and propagated to the test runner. The resulting traceback isn't actually useful. I'd like to change the test runner to capture BdbQuit and print a message to stdout before exiting instead of dumping the traceback. Any reason this would be a bad idea? -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 22 Jul '08

22 Jul '08

Summary of messages to the zope-tests list. Period Mon Jul 21 11:00:00 2008 UTC to Tue Jul 22 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Mon Jul 21 21:05:07 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009890.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon Jul 21 21:06:38 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009891.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon Jul 21 21:08:08 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009892.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon Jul 21 21:09:38 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009893.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon Jul 21 21:11:08 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009894.html

1 0