Re: [Zope-dev] Avoid deprecation warnings in the testrunner
On Dec 24, 2009, at 10:13 AM, Fabio Tranchitella wrote:
* 2009-12-24 15:43, Zvezdan Petkovic wrote:
You did not import zope.testing.doctest, but the reference to it remains. I don't think that's a fix.
You are right, I committed the right fix.
I was just about to commit the same thing + the removal of the dependency on zope.testing in setup.py. I committed that second part now. Before I release the egg on PyPI: 1. Should we release as 1.1.2 (a minor change), or 2. Does the removal of dependency on zope.testing warrants a bump to 1.2.0? FWIW, I preferred zope.testing.doctest reporting of 15 tests because that's the actual number of things being tested in that file, while Python doctest reports 1 test only, because that's a number of test files being run. Zvezdan
* 2009-12-24 16:20, Zvezdan Petkovic wrote:
Before I release the egg on PyPI:
1. Should we release as 1.1.2 (a minor change), or 2. Does the removal of dependency on zope.testing warrants a bump to 1.2.0?
I think 1.1.2 is okey, you are not changing any behaviour of the package.
FWIW, I preferred zope.testing.doctest reporting of 15 tests because that's the actual number of things being tested in that file, while Python doctest reports 1 test only, because that's a number of test files being run.
Me too, maybe we should push the changes to doctest upstream to Python? Best regards, Fabio
On Dec 24, 2009, at 10:26 AM, Fabio Tranchitella wrote:
* 2009-12-24 16:20, Zvezdan Petkovic wrote:
Before I release the egg on PyPI:
1. Should we release as 1.1.2 (a minor change), or 2. Does the removal of dependency on zope.testing warrants a bump to 1.2.0?
I think 1.1.2 is okey, you are not changing any behaviour of the package.
zope.minmax-1.1.2 is now on PyPI.
FWIW, I preferred zope.testing.doctest reporting of 15 tests because that's the actual number of things being tested in that file, while Python doctest reports 1 test only, because that's a number of test files being run.
Me too, maybe we should push the changes to doctest upstream to Python?
That will take some serious persuading. We could argue the above, i.e., that 15 different things were tested in one doctest file. Unfortunately, when a single test in a doctest file is mixed with prose descriptions to explain parts of the test, zope.testing.doctest counts it as a separate test. This was considered a misfeature in the past and would probably be rejected for the same reason now. People are divided in opinion on this and whenever that happens it's hard to push such a change upstream into Python library. Of course, it may be worth trying if there is a critical mass of supporters. Zvezdan
On Thu, Dec 24, 2009 at 10:52 AM, Zvezdan Petkovic <zvezdan@zope.com> wrote:
Of course, it may be worth trying if there is a critical mass of supporters.
Alternately, there could be a way of extending the standard doctest to achieve this "feature" without pushing it into the standard library. I'm ambivalent on the value of the feature itself. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Thu, Dec 24, 2009 at 10:52 AM, Zvezdan Petkovic <zvezdan@zope.com> wrote:
On Dec 24, 2009, at 10:26 AM, Fabio Tranchitella wrote:
* 2009-12-24 16:20, Zvezdan Petkovic wrote:
...
FWIW, I preferred zope.testing.doctest reporting of 15 tests because that's the actual number of things being tested in that file, while Python doctest reports 1 test only, because that's a number of test files being run.
Me too, maybe we should push the changes to doctest upstream to Python?
That will take some serious persuading.
We could argue the above, i.e., that 15 different things were tested in one doctest file.
Unfortunately, when a single test in a doctest file is mixed with prose descriptions to explain parts of the test, zope.testing.doctest counts it as a separate test.
This was considered a misfeature in the past and would probably be rejected for the same reason now.
I think there was some consensus for an alternate algorithm: count each example that has output.
People are divided in opinion on this and whenever that happens it's hard to push such a change upstream into Python library.
Of course, it may be worth trying if there is a critical mass of supporters.
I'm too lazy to try something like that. I think dealing with stuff in the standard library is too much of a pain. I recommend shifting focus to manuel. I hope manuel is never added to the standard library. :) Jim -- Jim Fulton
participants (4)
-
Fabio Tranchitella -
Fred Drake -
Jim Fulton -
Zvezdan Petkovic