March 2010 - Zope-Dev

z3c.form - ComputedErrorViewMessage and crazy adapter behaviour
by Martin Aspeli 09 Mar '10

09 Mar '10

Hi, I posted about this earlier, but the message seems to have gotten lost in the ether. I am trying and struggling to use ComputedErrorViewMessage. So far, I've discovered two problems, one which affects IValue adapters in general. 1. The last discriminator of a ComputedErrorViewMessage (and an ErrorViewMessage) is listed as 'content': ErrorViewMessage = value.StaticValueCreator( discriminators = ('error', 'request', 'widget', 'field', 'form', 'content') ) ComputedErrorViewMessage = value.ComputedValueCreator( discriminators = ('error', 'request', 'widget', 'field', 'form', 'content') ) However, the adapter lookup further down in error.py does: class ErrorViewSnippet(object): ... def update(self): value = zope.component.queryMultiAdapter( (self.context, self.request, self.widget, self.field, self.form, self), interfaces.IValue, name='message') if value is not None: self.message = value.get() else: self.message = self.createMessage() Notice how the last parameter is 'self', i.e. the ErrorViewSnippet. To me, at least, 'content' suggests this refers to the value returned by form.getContent(), most likely form.context. There's no test for this discriminator that I can see, so I'm not sure whether the "bug" is that 'content' is a poor name, or if the last part of that tuple should be self.form.getContent() or self.form.context? 2. The order in which we use ErrorViewMessage or ComputedErrorViewMessage seems to make a difference to its ability to specialise. I really can't figure out what the bug is, though. I've captured and annotated an interpreter session to illustrate the problem: First, some imports: >>> from zope.interface import Interface >>> from zope.component import provideAdapter >>> from zope import schema >>> from zope.schema.interfaces import TooSmall >>> from z3c.form import form, error, field >>> from z3c.form.testing import setupFormDefaults, TestRequest Set up a test environment with two forms. >>> setupFormDefaults() >>> class DummyContext(object): ... pass >>> context = DummyContext() >>> class ISchema(Interface): ... field1 = schema.Int(min=10) >>> class Form1(form.Form): ... fields = field.Fields(ISchema) ... ignoreContext = True >>> class Form2(form.Form): ... fields = field.Fields(ISchema) ... ignoreContext = True Define two error message value adapters. Note that message2 is a specialisation of message1, that also takes the form into account. Also note that message1 (the more general) happens to be created first. >>> message1 = error.ErrorViewMessage(u"Message 1", error=TooSmall, field=ISchema['field1']) >>> message2 = error.ErrorViewMessage(u"Message 2", error=TooSmall, field=ISchema['field1'], form=Form2) Now register these adapters (the order doesn't matter) >>> provideAdapter(message1, name=u"message") >>> provideAdapter(message2, name=u"message") Let's now create an instance of Form1 and try to validate it. >>> form1 = Form1(context, TestRequest(form={'form.widgets.field1': '5'})) >>> form1.update() >>> data, errors = form1.extractData() >>> len(errors) 1 >>> errors[0].message u'Message 1' No surprises there. Now let's try Form2. We'd expect to see message2, since it is registered for the more specific form: >>> form2 = Form2(context, TestRequest(form={'form.widgets.field1': '5'})) >>> form2.update() >>> data, errors = form2.extractData() >>> len(errors) 1 >>> errors[0].message u'Message 1' Ouch. Why is our more specific adapter being ignored? Recall that the ErrorViewSnippet does the IValue adapter lookup like so: value = zope.component.queryMultiAdapter( (self.context, self.request, self.widget, self.field, self.form, self), interfaces.IValue, name='message') The adapted objects are: >>> (errors[0].context, errors[0].request, errors[0].widget, errors[0].field, errors[0].form, errors[0]) (TooSmall(5, 10), <z3c.form.testing.TestRequest instance URL=http://127.0.0.1>, <TextWidget 'form.widgets.field1'>, <zope.schema._bootstrapfields.Int object at 0x1030a1190>, <__main__.Form2 object at 0x1035c0b90>, <ErrorViewSnippet for TooSmall>) Let's look at the interfaces provided by ISchema['field1']: >>> from zope.interface import directlyProvidedBy >>> list(directlyProvidedBy(ISchema['field1']).flattened()) [<InterfaceClass z3c.form.util.IGeneratedForObject_4345958800>, <InterfaceClass z3c.form.util.IGeneratedForObject_4345958800>, <InterfaceClass zope.interface.Interface>] >>> Let's also look at what our adapters are actually adapting: >>> message1.__component_adapts__ (<class 'zope.schema._bootstrapinterfaces.TooSmall'>, None, None, <InterfaceClass z3c.form.util.IGeneratedForObject_4345958800>, None, None) >>> message2.__component_adapts__ (<class 'zope.schema._bootstrapinterfaces.TooSmall'>, None, None, <InterfaceClass z3c.form.util.IGeneratedForObject_4345958800>, <class '__main__.Form2'>, None) Our adapters are both in the registry: >>> from z3c.form.interfaces import IValue >>> from pprint import pprint >>> from zope.component import getSiteManager >>> pprint([r for r in getSiteManager().registeredAdapters() if r.provided == IValue]) [AdapterRegistration(<BaseGlobalComponents base>, [zope.schema._bootstrapinterfaces.TooSmall, Interface, Interface, IGeneratedForObject_4345958800, __main__.Form2, Interface], IValue, u'message', <z3c.form.value.ValueFactory object at 0x1030a1690>, u''), AdapterRegistration(<BaseGlobalComponents base>, [zope.schema._bootstrapinterfaces.TooSmall, Interface, Interface, IGeneratedForObject_4345958800, Interface, Interface], IValue, u'message', <z3c.form.value.ValueFactory object at 0x10268e390>, u'')] Sigh. Let's try again, this time creating the value adapters in the opposite order: >>> from zope.interface import Interface >>> from zope.component import provideAdapter >>> from zope import schema >>> from zope.schema.interfaces import TooSmall >>> from z3c.form import form, error, field >>> from z3c.form.testing import setupFormDefaults, TestRequest Set up a test environment with two forms. >>> setupFormDefaults() >>> class DummyContext(object): ... pass >>> context = DummyContext() >>> class ISchema(Interface): ... field1 = schema.Int(min=10) >>> class Form1(form.Form): ... fields = field.Fields(ISchema) ... ignoreContext = True >>> class Form2(form.Form): ... fields = field.Fields(ISchema) ... ignoreContext = True Define two error message value adapters. Note that message2 is a specialisation of message1, that also takes the form into account. Also note that message2 (the more specific) happens to be created first. >>> message2 = error.ErrorViewMessage(u"Message 2", error=TooSmall, field=ISchema['field1'], form=Form2) >>> message1 = error.ErrorViewMessage(u"Message 1", error=TooSmall, field=ISchema['field1']) Now register these adapters (the order doesn't matter) >>> provideAdapter(message1, name=u"message") >>> provideAdapter(message2, name=u"message") Let's now create an instance of Form1 and try to validate it. >>> form1 = Form1(context, TestRequest(form={'form.widgets.field1': '5'})) >>> form1.update() >>> data, errors = form1.extractData() >>> len(errors) 1 >>> errors[0].message u'Message 1' No surprises there. Now let's try Form2. This time, we get "Message 2" >>> form2 = Form2(context, TestRequest(form={'form.widgets.field1': '5'})) >>> form2.update() >>> data, errors = form2.extractData() >>> len(errors) 1 >>> errors[0].message u'Message 2' Let's also check the registry: >>> (errors[0].context, errors[0].request, errors[0].widget, errors[0].field, errors[0].form, errors[0]) (TooSmall(5, 10), <z3c.form.testing.TestRequest instance URL=http://127.0.0.1>, <TextWidget 'form.widgets.field1'>, <zope.schema._bootstrapfields.Int object at 0x10309b810>, <__main__.Form2 object at 0x10392bd50>, <ErrorViewSnippet for TooSmall>) >>> from zope.interface import directlyProvidedBy >>> list(directlyProvidedBy(ISchema['field1']).flattened()) [<InterfaceClass z3c.form.util.IGeneratedForObject_4345935888>, <InterfaceClass z3c.form.util.IGeneratedForObject_4345935888>, <InterfaceClass zope.interface.Interface>] >>> message1.__component_adapts__ (<class 'zope.schema._bootstrapinterfaces.TooSmall'>, None, None, <InterfaceClass z3c.form.util.IGeneratedForObject_4345935888>, None, None) >>> message2.__component_adapts__ (<class 'zope.schema._bootstrapinterfaces.TooSmall'>, None, None, <InterfaceClass z3c.form.util.IGeneratedForObject_4345935888>, <class '__main__.Form2'>, None) >>> from z3c.form.interfaces import IValue >>> from pprint import pprint >>> from zope.component import getSiteManager >>> pprint([r for r in getSiteManager().registeredAdapters() if r.provided == IValue]) [AdapterRegistration(<BaseGlobalComponents base>, [zope.schema._bootstrapinterfaces.TooSmall, Interface, Interface, IGeneratedForObject_4345935888, Interface, Interface], IValue, u'message', <z3c.form.value.ValueFactory object at 0x10309bd10>, u''), AdapterRegistration(<BaseGlobalComponents base>, [zope.schema._bootstrapinterfaces.TooSmall, Interface, Interface, IGeneratedForObject_4345935888, __main__.Form2, Interface], IValue, u'message', <z3c.form.value.ValueFactory object at 0x10309ba10>, u'')] If there's a difference here, I can't see it. Martin

1 0

Zope Tests: 6 OK
by Zope Tests Summarizer 09 Mar '10

09 Mar '10

Summary of messages to the zope-tests list. Period Mon Mar 8 12:00:00 2010 UTC to Tue Mar 9 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 8 20:36:56 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013702.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 8 20:38:57 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013703.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 8 20:40:57 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013704.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 8 20:42:57 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013705.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 8 20:44:57 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013706.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 8 20:46:57 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013707.html

1 0

Agenda for today's IRC meeting (3pm UTC on #zope)
by Christian Theune 09 Mar '10

09 Mar '10

Agenda for today's IRC meeting at 3pm UTC on #zope Hi, continuing the experiment of weekly meetings, here's the reminder for today's meeting including the proposed agenda. Time and place is, again, 3pm UTC at #zope@freenode. If you'd like to review last week's summary, please check here: https://mail.zope.org/pipermail/zope-dev/attachments/20100302/60a8224d/atta… Agenda ------ These are agenda items compiled from last weeks summary and input from the community: - Test runners / nightly builds (10 minutes) - Volunteer for coordinating automated builds - Towards a list of projects/platforms/etc. we want guaranteed builds for - Access to Windows (2003) build machines for developers (Baiju M.) - Towards a ZTK release (10 minutes) - What is needed for a release? - Who's the release manager? - Can we ensure building Windows binaries? - Bug tracking / working on bugs regularly (5 minutes) - Wrap-up (5 minutes) Horizon ------- These items are currently tracked on the horizon: we won't discuss them at this meeting, but we'll get to them at some point: - How do we deal with proposed API changes and Python 3 compatibility? (Lennart Regebro) - Pondering *some* (re-)structuring of the ZTK to allow for better maintenance/release management/communication/marketing. (Chris McDonough) -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development

1 0

z3c.form - ComputedErrorViewMessage
by Martin Aspeli 09 Mar '10

09 Mar '10

Hi, I'm struggling to get custom ComputedErrorViewMessage adapters to work in z3c.form. I'm still debugging, but I came across this: In error.py: ErrorViewMessage = value.StaticValueCreator( discriminators = ('error', 'request', 'widget', 'field', 'form', 'content') ) ComputedErrorViewMessage = value.ComputedValueCreator( discriminators = ('error', 'request', 'widget', 'field', 'form', 'content') ) class ErrorViewSnippet(object): ... def update(self): value = zope.component.queryMultiAdapter( (self.context, self.request, self.widget, self.field, self.form, self), interfaces.IValue, name='message') if value is not None: self.message = value.get() else: self.message = self.createMessage() ... From what I can tell, self.context is the exception; self.request, self.widget, self.field and self.form are as you'd expect. But the last discriminator, 'content' does not match up with 'self' (i.e. the error view snippet). So, which is right? The discriminator on the value adapter factory, or the multi-adapter lookup? The documentation mentions 'content' as the discriminator, but doesn't define it any further. FWIW, my expection is that 'content' should be the form's context content object. Martin

1 0

vyshakh krishnan wants to chat
by vyshakh krishnan 08 Mar '10

08 Mar '10

----------------------------------------------------------------------- vyshakh krishnan wants to stay in better touch using some of Google's coolest new products. If you already have Gmail or Google Talk, visit: http://mail.google.com/mail/b-dbd6bff667-b1982e48b6-0879284f0da0a451 You'll need to click this link to be able to chat with vyshakh krishnan. To get Gmail - a free email account from Google with over 2,800 megabytes of storage - and chat with vyshakh krishnan, visit: http://mail.google.com/mail/a-dbd6bff667-b1982e48b6-0879284f0da0a451 Gmail offers: - Instant messaging right inside Gmail - Powerful spam protection - Built-in search for finding your messages and a helpful way of organizing emails into "conversations" - No pop-up ads or untargeted banners - just text ads and related information that are relevant to the content of your messages All this, and its yours for free. But wait, there's more! By opening a Gmail account, you also get access to Google Talk, Google's instant messaging service: http://www.google.com/talk/ Google Talk offers: - Web-based chat that you can use anywhere, without a download - A contact list that's synchronized with your Gmail account - Free, high quality PC-to-PC voice calls when you download the Google Talk client We're working hard to add new features and make improvements, so we might also ask for your comments and suggestions periodically. We appreciate your help in making our products even better! Thanks, The Google Team To learn more about Gmail and Google Talk, visit: http://mail.google.com/mail/help/about.html http://www.google.com/talk/about.html (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser).

3 2

Zope Tests: 6 OK
by Zope Tests Summarizer 08 Mar '10

08 Mar '10

Summary of messages to the zope-tests list. Period Sun Mar 7 12:00:00 2010 UTC to Mon Mar 8 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 7 20:36:45 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013696.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 7 20:38:45 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013697.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sun Mar 7 20:40:45 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013698.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Mar 7 20:42:45 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013699.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sun Mar 7 20:44:45 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013700.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sun Mar 7 20:46:45 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013701.html

1 0

Automating tests of the ZTK / zopeapp package sets
by Tres Seaver 07 Mar '10

07 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After successfully configuring the Hudson[1] continuous integration server yesterday to test the various repoze.* packages[2], I thought I would experiment with using it to drive the compatibility tests for ZTK and zopeapp. Here is what I did: In a shell on my server: $ wget http://hudson-ci.org/latest/hudson.war $ java -jar hudson.war --httpPort=19999 .... In the browser, visit 'http://laguna.palladion.com:19999, and configure the server: - - Enable security - allow signup - using Matrix - set up 'tseaver' as having all permissions - set up 'anonymous' as having 'Read' permission overall and for jobs - - Register as 'tseaver' - Turn off signup (no, I don't want you guys running arbitrary shell scripts on my server ;). - - Create a job, 'ztk-trunk-py26': http://laguna.palladion.com:19999/job/ztk-trunk-py26/ - Use SVN, pointed at 'svn://svn.zope.org/repos/main/zopetoolkit/trunk' - Set to poll SVN every 15 minutes. - Enable using 'svn up' - Added build step as a shell script:: cd trunk /opt/Python-2.6.4/bin/python bootstrap.py bin/buildout bin/test-ztk bin/test-zopeapp - Ran a build manually. The first one barfed due to a typo in my script, but the second one ran, taking 21 minutes. The test runs successfully to completion, but doesn't produce statistics in a form that Hudson understands. The following changes to 'zope.testing.testrunner' would make the output more informative: - Add a flag like the '--with-xunit' flag to the Nose testrunner, which dumped results into a JUnit-compatible XML file[3]. - Add a flag like the '--with-xcompat' flag to the Nose testrunner (when run with the 'nosexcover' plugin), producing a Cobertura- compabtible XML file[4]. At that point, the build process would be nicely automated, with browsable results including coverage, pretty graphs, etc. See the 'repoze' jobs for examples of those outputs. Questions for discussion: - - I find the prettier interface and easier setup than buildbot worth running a 3rd-party Java app (rather than a 3rd party Python app). Would that be acceptable among the folks running our automated tests? - - Is it worth adding the XML support for test results and coverage to 'zope.testing.testrunner'? - - Would people be willing to run Hudson "permanently" on enough hosts to make this a reasonable replacement for buildbot (we need Windows, too)? - - Hudson seems general purpose enough to allow automating other code- related tasks, e.g., production of dependency graphs. Maybe we could even automate building Windows installers? I will try to leave the ZTK Hudson server up for a little bit, to allow folks to see what it can deliver already. [1] http://hudson-ci.org/ [2] http://hudson.repoze.org/ [3] http://old.nabble.com/schema-for-junit-xml-output-td22193385.html [4] http://cobertura.sourceforge.net/xml/coverage-01.dtd 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQIcAACgkQ+gerLs4ltQ61pACfXsIdiRGY2LQ+u8d/qpG2okpT eKQAn0gjegHqlvu7w3RV01IruUx7S5QM =OmZN -----END PGP SIGNATURE-----

7 7

Zope Tests: 6 OK
by Zope Tests Summarizer 07 Mar '10

07 Mar '10

Summary of messages to the zope-tests list. Period Sat Mar 6 12:00:00 2010 UTC to Sun Mar 7 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Mar 6 20:45:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013690.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Mar 6 20:47:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013691.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:49:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013692.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:51:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013693.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:53:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013694.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Mar 6 20:55:12 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013695.html

1 0

Version bumping in the trunk after release
by Baiju M 07 Mar '10

07 Mar '10

Hi, I would propose a one word change in the "Releasing Software" document which is part of process documentation for zopetookit. After preparing a release, developer increase next version number to next feature version or next bugfix version. From the explanation given there, it is very obvious that the number should be changed to next bugfix release. I think the wording also should be changed, so that there won't be any confusion. This sentence: Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* release while preserving the ``dev`` marker. Should be changed to: Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. If there is no objection, I am going to make this change after 3 days. To understand the context, here is the full text: 6. Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. The convention is that the trunk or release branch always points to the upcoming release, *not* the one that has been released already. So if you've just released version 3.4.1, you should change ``setup.py`` to read:: setup( name='...', version='3.4.2dev', ... ) In ``CHANGES.txt`` add a *new* section for the upcoming release. The release date for that should say "unreleased" so that committers recording their changes won't accidentally put their entry in the section for an already released version. For example:: 3.4.2 (unreleased) ------------------ * ... 3.4.1 (2007-01-24) ------------------ * Fixed bug in the foo adapter. * Added a bar utility for optimized kaboodling. 3.4.0 (2006-09-13) ------------------ Initial release as separate egg. Regards, Baiju M Index: source/process/releasing-software.rst =================================================================== --- source/process/releasing-software.rst (revision 109748) +++ source/process/releasing-software.rst (working copy) @@ -74,7 +74,7 @@ versions and linking models (framework / non-framework). 6. Back on the trunk or the release branch, increase the version - number in ``setup.py`` to the *next* release while preserving the + number in ``setup.py`` to the *next* bugfix release while preserving the ``dev`` marker. The convention is that the trunk or release branch always points to the upcoming release, *not* the one that has been released already. So if you've just released version 3.4.1, you

1 0

Re: [Zope-dev] SVN: DateTime/trunk/src/DateTime/tests/testDateTime.py add a failing test for a regression in parsing ISO format datetimes from DateTime 2.10, as discussed at http://dev.plone.org/plone/ticket/10140 ...note that this will give a false positive if run on a computer where GMT is the local timezone
by Tres Seaver 07 Mar '10

07 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Glick wrote: > Log message for revision 109667: > add a failing test for a regression in parsing ISO format datetimes from DateTime 2.10, as discussed at http://dev.plone.org/plone/ticket/10140 ...note that this will give a false positive if run on a computer where GMT is the local timezone Please don't deliberately check in failing tests on the trunk. If you need to do this, make a branch, and ask on the mailing list for people to investigate your branch. > Changed: > U DateTime/trunk/src/DateTime/tests/testDateTime.py > > -=- > Modified: DateTime/trunk/src/DateTime/tests/testDateTime.py > =================================================================== > --- DateTime/trunk/src/DateTime/tests/testDateTime.py 2010-03-05 03:41:57 UTC (rev 109666) > +++ DateTime/trunk/src/DateTime/tests/testDateTime.py 2010-03-05 07:04:12 UTC (rev 109667) > @@ -332,6 +332,7 @@ > ref2 = DateTime('2006/11/6 10:30 GMT') > ref3 = DateTime('2004/06/14 14:30:15 GMT-3') > ref4 = DateTime('2006/01/01 GMT') > + ref5 = DateTime('2006/01/01') Note that this a nonreproducible test value: parsing the string with slashes but no timezone always gives you "local time". 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuRWQQACgkQ+gerLs4ltQ7fUwCg1sqO48X6vjW/pgyq+2I4OGV0 j/IAn0/IZy+/d9+O/nEykkTLBLVYxdua =paH6 -----END PGP SIGNATURE-----

2 2