My app's buildbot went all red last night, because its config wants the latest zope.testing (for our developers' convenience), and the latest zope.testing release no longer ships its own copy of doctest.py, I guess: from zope.testing.doctestunit import DocTestSuite ImportError: cannot import name DocTestSuite Does anybody have any objections for a BBB import, making DocTestSuite available from the old location? I don't think breaking API is appropriate in a point-release (3.8.4), so I'd like to release 3.8.5 with that fixed. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Sun, Dec 20, 2009 at 17:36, Marius Gedminas <marius@gedmin.as> wrote:
My app's buildbot went all red last night, because its config wants the latest zope.testing (for our developers' convenience), and the latest zope.testing release no longer ships its own copy of doctest.py, I guess:
No, it's still there.
from zope.testing.doctestunit import DocTestSuite
doctestunit? It's in doctest. That line should be: from zope.testing.doctest import DocTestSuite -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Sun, Dec 20, 2009 at 11:12:14PM +0100, Lennart Regebro wrote:
On Sun, Dec 20, 2009 at 17:36, Marius Gedminas <marius@gedmin.as> wrote:
My app's buildbot went all red last night, because its config wants the latest zope.testing (for our developers' convenience), and the latest zope.testing release no longer ships its own copy of doctest.py, I guess:
No, it's still there.
from zope.testing.doctestunit import DocTestSuite
doctestunit? It's in doctest. That line should be:
from zope.testing.doctest import DocTestSuite
Good, it means I can run a global search-and-replace over my project and go back to using the latest test runner. I don't know if 'doctestunit' was ever a part of the official zope.testing API, I just know that I've learned to use from zope.testing.doctestunit import DocTestSuite somewhere (Jim's PyCon presentation? Ancient Zope 3 source tree?), used it that way for many years, never got as much as a deprecation warning, and now suddenly disappeared in a bugfix release. *shrug* Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Sun, Dec 20, 2009 at 23:55, Marius Gedminas <marius@gedmin.as> wrote:
I don't know if 'doctestunit' was ever a part of the official zope.testing API, I just know that I've learned to use
I've looked through the history of doctestunit, and it seems like it once was. This was changed 5 years ago, and doctestunit was left with BBB imports without comments and without deprecation. Then they was removed in a cleanup, as they simply was unused imports. This probably should be reverted. I'll add them back with deprecations, and also deprecate zope.testing.doctest in general. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
On Mon, Dec 21, 2009 at 10:32:42AM +0100, Lennart Regebro wrote:
On Sun, Dec 20, 2009 at 23:55, Marius Gedminas <marius@gedmin.as> wrote:
I don't know if 'doctestunit' was ever a part of the official zope.testing API, I just know that I've learned to use
So, Monday! I take a deeper look at the codebase, and I see that only two test files written way back in 2004, in the very oldest corner of the code used doctestunit in this way. IOW thanks for the wake-up call, those two files got promptly fixed. I'll try collect more info before spewing off next time.
I've looked through the history of doctestunit, and it seems like it once was. This was changed 5 years ago, and doctestunit was left with BBB imports without comments and without deprecation.
Then they was removed in a cleanup, as they simply was unused imports.
This probably should be reverted. I'll add them back with deprecations, and also deprecate zope.testing.doctest in general.
Can you please make it a PendingDeprecationWarning first? There were actual bugfixes in zope.testing.doctest that weren't present in the stdlib's doctest.py (e.g. bin/test --coverage would stop working if any module imported doctest). I still have one production instance running on Python 2.4 (hopefully not for too long), and I'm not sure if doctest was sufficiently fixed in 2.4. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Mon, Dec 21, 2009 at 02:20:54PM +0200, Marius Gedminas wrote:
On Mon, Dec 21, 2009 at 10:32:42AM +0100, Lennart Regebro wrote:
On Sun, Dec 20, 2009 at 23:55, Marius Gedminas <marius@gedmin.as> wrote:
I don't know if 'doctestunit' was ever a part of the official zope.testing API, I just know that I've learned to use
So, Monday! I take a deeper look at the codebase, and I see that only two test files written way back in 2004, in the very oldest corner of the code used doctestunit in this way. IOW thanks for the wake-up call, those two files got promptly fixed.
I'll try collect more info before spewing off next time.
Speaking of "more info", looks like this change bit zope.container (trunk as well as the last stable release 3.10.0) too: Test-module import failures: Module: zope.container.tests.test_btree Traceback (most recent call last): File "/home/mg/src/zope.container/src/zope/container/tests/test_btree.py", line 20, in <module> from zope.testing.doctestunit import DocTestSuite ImportError: cannot import name DocTestSuite Module: zope.container.tests.test_ordered Traceback (most recent call last): File "/home/mg/src/zope.container/src/zope/container/tests/test_ordered.py", line 19, in <module> from zope.testing.doctestunit import DocTestSuite ImportError: cannot import name DocTestSuite Running tests at level 1 Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Running: Ran 173 tests with 0 failures and 0 errors in 1.529 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Test-modules with import problems: zope.container.tests.test_btree zope.container.tests.test_ordered Do we have a buildbot of all latest Zope packages? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Mon, Dec 21, 2009 at 13:20, Marius Gedminas <marius@gedmin.as> wrote:
Can you please make it a PendingDeprecationWarning first?
Yeah, I guess, but why? Yes, it had bugfixes, and I have monkey-patches of doctest in the branch to fix them. But it's not like they are going to get fixed in 2.4 because we wait with deprecating the custom doctest. :) The main reason for it was that it wasn't included in Python 2.3. We don't want to support Python 2.3 anymore. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
On Mon, Dec 21, 2009 at 07:41:24PM +0100, Lennart Regebro wrote:
On Mon, Dec 21, 2009 at 13:20, Marius Gedminas <marius@gedmin.as> wrote:
Can you please make it a PendingDeprecationWarning first?
Yeah, I guess, but why?
Because I hate it when my code emits DeprecationWarnings, and I wasn't sure I could throw a switch and migrate to stdlib's doctest.py today without extensive tests/preparation. Key word being "wasn't". I migrated my codebase to use stdlib's doctest.py today, and nothing broke, to my surprise. Even coverage support continues to work fine (at some point just having 'import doctest' could make bin/test --coverage forget about half the code it's seen). So, I'm fine with a DeprecationWarning. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Mon, Dec 21, 2009 at 22:23, Marius Gedminas <marius@gedmin.as> wrote:
On Mon, Dec 21, 2009 at 07:41:24PM +0100, Lennart Regebro wrote:
On Mon, Dec 21, 2009 at 13:20, Marius Gedminas <marius@gedmin.as> wrote:
Can you please make it a PendingDeprecationWarning first?
Yeah, I guess, but why?
Because I hate it when my code emits DeprecationWarnings, and I wasn't sure I could throw a switch and migrate to stdlib's doctest.py today without extensive tests/preparation.
Key word being "wasn't".
I migrated my codebase to use stdlib's doctest.py today, and nothing broke, to my surprise. Even coverage support continues to work fine (at some point just having 'import doctest' could make bin/test --coverage forget about half the code it's seen).
So, I'm fine with a DeprecationWarning.
Good to hear. I thought they should work, the differences are mostly in output formatting and such. I added the imports back, and also some deprecation warnings, although I'm not sure how to best add them, so I just stuck them in the modules, so the first import will raise a warning. A new release would be great, I guess. Christian, what do you say? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Mon, Dec 21, 2009 at 10:27:01PM +0100, Lennart Regebro wrote:
I added the imports back, and also some deprecation warnings, although I'm not sure how to best add them,
Maybe zope.deprecation can help?
so I just stuck them in the modules, so the first import will raise a warning. A new release would be great, I guess. Christian, what do you say?
The warning in zope.testing.doctestunit says "zope.testing.doctest is deprecated", I think it should say "doctestunit". I fixed that in svn (and added stacklevel=2, so you can see where in your code those modules are imported). Should zope.testing.doctestunit.pprint be deprecated? It's trying to fix a misfeature of stdlib's pprint.pprint, which is that pprinting a dict will output its repr() if len(repr(a_dict)) is narrower than the desired wrapping width. The order of keys and values of a dict's repr() is not well-defined, which tends to cause issues for doctests. zope.testing.doctestunit.pprint works around it by hardcoding the wrapping width to 1, which results in somewhat ugly output, but forces the stdlib's pretty-printer to sort dict keys alphabetically. I don't have strong feelings one way or another. I have 18 test files that use zope.testing.doctestunit.pprint, but since I always found its output ugly, I wouldn't mind writing some custom dict printing functions. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Tue, Dec 22, 2009 at 10:26, Marius Gedminas <marius@gedmin.as> wrote:
On Mon, Dec 21, 2009 at 10:27:01PM +0100, Lennart Regebro wrote:
I added the imports back, and also some deprecation warnings, although I'm not sure how to best add them,
Maybe zope.deprecation can help?
I didn't find anything obvious.
The warning in zope.testing.doctestunit says "zope.testing.doctest is deprecated", I think it should say "doctestunit".
Oups.
I fixed that in svn (and added stacklevel=2, so you can see where in your code those modules are imported).
Ah, right. Forgot that.
Should zope.testing.doctestunit.pprint be deprecated?
It's trying to fix a misfeature of stdlib's pprint.pprint, which is that pprinting a dict will output its repr() if len(repr(a_dict)) is narrower than the desired wrapping width. The order of keys and values of a dict's repr() is not well-defined, which tends to cause issues for doctests. zope.testing.doctestunit.pprint works around it by hardcoding the wrapping width to 1, which results in somewhat ugly output, but forces the stdlib's pretty-printer to sort dict keys alphabetically.
Aha.
I don't have strong feelings one way or another. I have 18 test files that use zope.testing.doctestunit.pprint, but since I always found its output ugly, I wouldn't mind writing some custom dict printing functions.
I have no opinion either, I don't use it, but it does seem slightly practical. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius Gedminas wrote:
On Mon, Dec 21, 2009 at 10:27:01PM +0100, Lennart Regebro wrote:
I added the imports back, and also some deprecation warnings, although I'm not sure how to best add them,
Maybe zope.deprecation can help?
Please not -- zope.deprecation ss a cure worse than the disease: it actually fakes a module proxy (defined in C, no less) into sys.modules! This is truly scary code: I guarantee that trying to trace through the same quasi-module with an unrelated bug is going to trip you up some day. As a side deficit, using the C proxy totally wrecks ano chance of using the package on non CPython. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAksxcWoACgkQ+gerLs4ltQ4itACfZS6lNbzB4jlIS1kgtaKtLbgl rAAAoJC0RteqNEpoWoKUsGwhccI+5v98 =t28Y -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 12/21/2009 10:27 PM, Lennart Regebro wrote: | On Mon, Dec 21, 2009 at 22:23, Marius Gedminas<marius@gedmin.as> wrote: |> On Mon, Dec 21, 2009 at 07:41:24PM +0100, Lennart Regebro wrote: |>> On Mon, Dec 21, 2009 at 13:20, Marius Gedminas<marius@gedmin.as> wrote: |>>> Can you please make it a PendingDeprecationWarning first? |>> |>> Yeah, I guess, but why? |> |> Because I hate it when my code emits DeprecationWarnings, and I wasn't |> sure I could throw a switch and migrate to stdlib's doctest.py today |> without extensive tests/preparation. |> |> Key word being "wasn't". |> |> I migrated my codebase to use stdlib's doctest.py today, and nothing |> broke, to my surprise. Even coverage support continues to work fine (at |> some point just having 'import doctest' could make bin/test --coverage |> forget about half the code it's seen). |> |> So, I'm fine with a DeprecationWarning. | | Good to hear. I thought they should work, the differences are mostly | in output formatting and such. | | I added the imports back, and also some deprecation warnings, although | I'm not sure how to best add them, so I just stuck them in the | modules, so the first import will raise a warning. A new release would | be great, I guess. Christian, what do you say? I'm sorry, I was out of the loop for a while. Is this about getting rid of our own doctest and relying on Python's standard doctest module? Christian - -- Christian Theune · ct@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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksx4hYACgkQdUt9X/gknwLqTwCgnCVClMa+I6DjeBa5Baqf/Foo JFEAn2rsUrEp+etmeOZHnIyCGPa2I91i =Jw/h -----END PGP SIGNATURE-----
On Wed, Dec 23, 2009 at 10:25, Christian Theune <ct@gocept.com> wrote:
Is this about getting rid of our own doctest and relying on Python's standard doctest module?
The deprecations are, yes. The problem (which has now been fixed) is that some BBB imports was not marked as being BBB imports and therefore was removed in a cleanup. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/23/2009 10:55 AM, Lennart Regebro wrote: | On Wed, Dec 23, 2009 at 10:25, Christian Theune<ct@gocept.com> wrote: |> Is this about getting rid of our own doctest and relying on Python's |> standard doctest module? | | The deprecations are, yes. The problem (which has now been fixed) is | that some BBB imports was not marked as being BBB imports and | therefore was removed in a cleanup. Sounds like regular maintenance for me then which I won't oppose regarding a release. On a related note: we're getting sloppy with the zope.testing releases AFAICT as the current minor version included several feature changes. I sneaked in the last one myself because I wanted to get rid of that review without having to think hard about the already broken branch. Nevertheless, I think the (agile, many, flexible, easy) releases and not branching the trunk at all start hurting us here as we're getting lost in our own policy. Any ideas for limiting feature creep? Christian - -- Christian Theune · ct@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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksx6d4ACgkQdUt9X/gknwLzYQCgwyC7AYcKtEKjt9byVDhRkrtH FQIAoK7ku/+gWcPEnO5GBPWYzPNuHK6N =HFJc -----END PGP SIGNATURE-----
On Wed, Dec 23, 2009 at 4:58 AM, Christian Theune <ct@gocept.com> wrote:
Nevertheless, I think the (agile, many, flexible, easy) releases and not branching the trunk at all start hurting us here as we're getting lost in our own policy. Any ideas for limiting feature creep?
Two comments: Whenever I wish I had created a major release branch (like /branches/1.5) at that point I go back and create one by copying the 1.5.0 tag. That way you have the best of both worlds, you don't have to remember to create major release branches (that you may never use) and you can have them if you end up doing significant maintenance on that version. As for having a broken trunk: I believe that every project needs a head maintainer that feels personally responsible for the state of a particular project. They would be in charge of reviewing and approving branches before they are merged to the project trunk. We've inherited a communal process from the pre-explosion days that worked well there, but there are just too many projects for the community to keep track of and to care for. -- Benji York
* 2009-12-23 16:13, Benji York wrote:
As for having a broken trunk: I believe that every project needs a head maintainer that feels personally responsible for the state of a particular project. They would be in charge of reviewing and approving branches before they are merged to the project trunk.
+1, we should make explicit who is responsible for which package. Zope2, Plone and other projects have the concept of "release manager", we don't have anybody responsible for the ZTK as a whole nor for a subset of the packages. Fabio
participants (6)
-
Benji York -
Christian Theune -
Fabio Tranchitella -
Lennart Regebro -
Marius Gedminas -
Tres Seaver