zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
And here is another interesting experiment: svn+ssh://regebro@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching It replaces the custom doctest.py with monkey-patches. I will report these to the Python bugtracker as well, although I have no hope of getting them into Python 2.7. But that doesn't matter much. :) Benefits: We don't have to maintain a separate doctest.py, and we get the bugfixes from Python. We haven't merged from Python trunk since 2004, and there are LOADS AND LOADS of bugfixes done on the Python doctest which we don't have. There are three bugfixes and two "features" that we have that I now monkey patch in in this branch. Drawbacks: If you import zope.testing.doctest, *all* your doctests will belong to us, so if you have doctests that expect the bugs, your out of luck. :) Also, I do not monkey-patch in the footer parsing support. It's too big, use Manuel instead if you need that. If noone protests, I'll merge this into my "no testrunner branch", make it support Python 3, and then merge that to trunk, maybe sometime next week. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
On Tuesday 20 April 2010, Lennart Regebro wrote:
It replaces the custom doctest.py with monkey-patches. I will report these to the Python bugtracker as well, although I have no hope of getting them into Python 2.7. But that doesn't matter much.
:)
Fantastic. I really hate the improper counting of the Python version. :-) BTW, I also like your splitting of the test runner and the testing infrastructure. The zope.testing testrunner is really good and deserves its own life. I hope that more people will pick it up. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On 4/20/10 13:37 , Stephan Richter wrote:
On Tuesday 20 April 2010, Lennart Regebro wrote:
It replaces the custom doctest.py with monkey-patches. I will report these to the Python bugtracker as well, although I have no hope of getting them into Python 2.7. But that doesn't matter much.
:)
Fantastic. I really hate the improper counting of the Python version. :-)
BTW, I also like your splitting of the test runner and the testing infrastructure. The zope.testing testrunner is really good and deserves its own life. I hope that more people will pick it up.
You may want to move it outside the zope.* namespace to encourage that :) Wichert.
On Tue, Apr 20, 2010 at 7:44 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
You may want to move it outside the zope.* namespace to encourage that :)
People interested in interfaces or component architectures don't seem to mind using zope.interface or zope.component; those get selected on their own merits with some frequency. I see no need to drop/replace the "zope." in the package name. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman <wichert@wiggy.net> wrote:
You may want to move it outside the zope.* namespace to encourage that :)
We could certainly do that. Jarrett - After Arthur Jarrett, convicted of the crime of making of gratuitous sexist jokes in a moving picture. Or maybe not. :) Other ideas?
On Tue, Apr 20, 2010 at 15:23, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman <wichert@wiggy.net> wrote:
You may want to move it outside the zope.* namespace to encourage that :)
We could certainly do that.
Jarrett - After Arthur Jarrett, convicted of the crime of making of gratuitous sexist jokes in a moving picture.
Or maybe not. :) Other ideas?
(zope.testrunner of course also being one perfectly good idea).
On Tuesday 20 April 2010, Lennart Regebro wrote:
(zope.testrunner of course also being one perfectly good idea).
I like zope.testrunner. If it gets its own Web site (eventually), we have a good place to guide people there. Regards. Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On 20 April 2010 21:23, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman <wichert@wiggy.net> wrote:
You may want to move it outside the zope.* namespace to encourage that :)
-1 I think zope.testrunner is just fine, and acknowledges the heritage. Namespaces should be about which community (or company) owns a package, not marketing. I think we're a little over-sensitive to the "it's Zope so we hate it" sentiment. The people (if any) who still have such childish ideas are probably not all that interesting to us as consumers of our software anyway. Martin
On 04/20/2010 03:59 PM, Martin Aspeli wrote:
On 20 April 2010 21:23, Lennart Regebro<regebro@gmail.com> wrote:
On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman<wichert@wiggy.net> wrote:
You may want to move it outside the zope.* namespace to encourage that :)
-1
I think zope.testrunner is just fine, and acknowledges the heritage. Namespaces should be about which community (or company) owns a package, not marketing. I think we're a little over-sensitive to the "it's Zope so we hate it" sentiment. The people (if any) who still have such childish ideas are probably not all that interesting to us as consumers of our software anyway.
And I'd like to retain my badge of being a proud Zope developer anyway. ;) -- 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
On Tue, Apr 20, 2010 at 15:23, Lennart Regebro <regebro@gmail.com> wrote:
On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman <wichert@wiggy.net> wrote:
You may want to move it outside the zope.* namespace to encourage that :)
We could certainly do that.
But the support for that idea seems very small, so let's stay with zope.testrunner, as it's perfectly good. And even py.test have problems struggling against Nose, so I don't think we'll get many non Zopers anyway. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Tue, Apr 20, 2010 at 4:46 AM, Lennart Regebro <regebro@gmail.com> wrote:
And here is another interesting experiment:
svn+ssh://regebro@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching
It replaces the custom doctest.py with monkey-patches. I will report these to the Python bugtracker as well, although I have no hope of getting them into Python 2.7. But that doesn't matter much. :)
Benefits: We don't have to maintain a separate doctest.py, and we get the bugfixes from Python. We haven't merged from Python trunk since 2004, and there are LOADS AND LOADS of bugfixes done on the Python doctest which we don't have. There are three bugfixes and two "features" that we have that I now monkey patch in in this branch.
Drawbacks: If you import zope.testing.doctest, *all* your doctests will belong to us, so if you have doctests that expect the bugs, your out of luck. :) Also, I do not monkey-patch in the footer parsing support. It's too big, use Manuel instead if you need that.
If noone protests, I'll merge this into my "no testrunner branch", make it support Python 3, and then merge that to trunk, maybe sometime next week.
Strong -1. Monkey patching should be used as a last resort. Monkey patching the standard library is likely to make us look like jack asses. We should switch to manuel, which already has the footnote feature. Let zope.testing.doctest wither and die, or reimplement it as a facade on manuel. Jim -- Jim Fulton
On Tue, Apr 20, 2010 at 20:35, Jim Fulton <jim@zope.com> wrote:
Monkey patching should be used as a last resort. Monkey patching the standard library is likely to make us look like jack asses.
Possibly. But having a doctest module with loads of bugs that doesn't even behave exactly the same maybe doesn't make us look like jackasses, but it sure as heck is a big pain, and makes zope.testing practically impossible to port to Python 3 in a sensible way. The monkey-patching makes it possible to remove the doctest module without all of zopes.* tests failing. The Deprecation warning of course should remain. It can be noted that my previous Python 3 porting efforts have simply deleted the doctest module. I believe these are the two options we have if we want ZTK to be ported to Python 3. So it's really a choice: Delete it and monkey patch, or delete it and break everything, or not supporting Python 3.
We should switch to manuel, which already has the footnote feature.
Oh, I'm *not* monkey-patching in the footnote feature. :) People using that feature will have to stay with an earlier zope.testing or switch to Manuel.
Let zope.testing.doctest wither and die
It hasn't been merged from python trunk since 2004, and the amount of bugfixes on that Python trunk since then is astounding. So I'd argue that is *is* withered. The monkey-patching kills it. :) Interestingly, there are two bugs fixed on zopes doctest that hasn't been fixed in the standard library. I've reported them: http://bugs.python.org/issue8471 http://bugs.python.org/issue8473 So that's two of the patches. The remaining two patches are: 1. zope doctests get the TestCases surrounding environment, while stdlib doctests you need to explicitly pass in extra environment. That patch is there for compatibility, some tests won't work otherwise. 2. stdlibs unittest will ignore all reporting flags given to the testrunner if any reporting flag is given to the test, most significantly also the -1 flag. I think that's daft, so I took it up on python-dev. Lastly doctest.DocTestCase.failureException is set to zope.testing.exceptions.DocTestFailureException, but that's not even a monkey-patch, that's how you are supposed to do it, so that's a part of the testrunner, really, and probably that "patching" should be done by the testrunner before it runs the tests instead, should be a simple fix. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Wed, Apr 21, 2010 at 07:10:38AM +0200, Lennart Regebro wrote:
Let zope.testing.doctest wither and die
It hasn't been merged from python trunk since 2004, and the amount of bugfixes on that Python trunk since then is astounding. So I'd argue that is *is* withered. The monkey-patching kills it. :)
Interestingly, there are two bugs fixed on zopes doctest that hasn't been fixed in the standard library. I've reported them:
*Thank you*, this was the only issue that caused me trouble when I ported our code base from zope.testing.doctest to stdlib's doctest. I ran out of tuits so I didn't report it. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
* Jim Fulton <jim@zope.com> [2010-04-20 20:35]:
On Tue, Apr 20, 2010 at 4:46 AM, Lennart Regebro <regebro@gmail.com> wrote:
And here is another interesting experiment: svn+ssh://regebro@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching It replaces the custom doctest.py with monkey-patches.
Benefits: We don't have to maintain a separate doctest.py, and we get the bugfixes from Python.
Strong -1.
Monkey patching should be used as a last resort. Monkey patching the standard library is likely to make us look like jack asses.
That might be so. I don't share that position, but I have a different point that I want to make: Regardless of whether monkey-patching the stdlib is or isn't a Bad Thing(tm), I think Lennart's approach is an *improvement* over the previous situation where we copied a file from the stdlib wholesale[1] -- in my opinion that's definitely worse than a monkey-patch. Wolfgang [1] I know, I know, it was actually the other way around. But still.
participants (9)
-
Christian Theune -
Fred Drake -
Jim Fulton -
Lennart Regebro -
Marius Gedminas -
Martin Aspeli -
Stephan Richter -
Wichert Akkerman -
Wolfgang Schnerring