[Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?

[Marius Gedminas]

On Wed, Dec 30, 2009 at 08:58:52AM +0100, Lennart Regebro wrote:
> On Tue, Dec 29, 2009 at 23:47, Marius Gedminas <marius at gedmin.as> wrote:
> > I don't know enough about the differences between stdlib's doctest.py
> > (in its various Python 2.4/2.5/2.6 incarnations) and
> > zope.testing.doctest, other than that I've seen diffs, they were
> > non-trivial, with bugfixes and new features; I've heard about
> > monkey-patching the stdlib's doctest.py (which fills me with dread; when
> > exactly is the monkey-patching performed?), and I'd rather not touch the
> > issue without either complete understanding or a very large test suite
> > (all of the packages that were in the Zope 3 KGS at the very least) run
> > on various platforms.
> 
> zope.testing runs a lot of doctests. Lot's and lot's.

Do you mean the test suite of zope.testing itself?  Yes, it's not tiny,
but that doesn't mean it is representative of all the other packages out
there that currently use zope.testing.doctest.

> In the Python 3
> branch I've moved them over to using stdlibs doctest. There was two
> bugs that are fixed in Zopes doctest that is not fixed in Pythons
> doctest. I've added monkey-patches on import for them.

On import of what?  zope.testing's __init__.py?

I think I found it: in regebro-python3-reloaded branch I see
zope.testing's __init__ doing 'import monkeys', which is

http://zope3.pov.lt/trac/browser/zope.testing/branches/regebro-python3-reloaded/src/zope/testing/monkeys.py

Would you mind terribly adding a couple of comments explaining why
DocTestCase __init__ and tearDown need to be patched?  Is that to
prevent the globs from keeping state between different tests?  Just
guessing, by looking at the most interesting thing that happens in the
overridden methods.

> Obviously they
> should also be reported upstream,

The word "should" meaning they haven't been?

What are the bugs?  The globs thing, and allowing mixed unicode + UTF-8
output inside doctests?

> but new releases won't remove the
> bugs in old releases, so the monkey patches need to stay anyway.

*nod*

> The alternative to this is that somebody port zopes doctest.py to
> Python 3, so we don't deprecate it but keep it separate, for ever
> adding to the frustration and complication in doing testing and in
> particular doctesting that persists.

I'm +1 for dropping the forked doctest.py, and I'm very grateful for
your Python-3-ification efforts of zope.stuff.

I'm -1 for leaving existing users of zope.testing.doctest hanging
without a known and documented migration path.

> >  * custom doctest exception formatting
> 
> What does that formatting actually do?

I don't remember, exactly, I was just grepping the diffs for
DocTestFailureException.  It's probably the bit that lets bin/test -c
colorize things like diffs, and tracebacks in doctest failures.
If that's the case, I'd truly hate to lose this feature, it helps me
immensely.

> >  * support for the INTERPRET_FOOTNOTES feature
> 
> Then they should use Manuel.

Good, so we have a migration path for this bit!

How mechanical can such a transformation be?  Is it sufficient to
replace

  zope.testing.doctest.DocFileSuite('foo.txt', **kw)

with

  manuel.testing.TestSuite(manuel.doctest.Manuel(), 'foo.txt', **kw)

or do we need other changes, like removing INTERPRET_FOOTNOTES from
optionflags and include the manuel.footnote.Manuel() in some way?

I've never used Manuel, I'm guessing what the syntax ought to be by
looking at http://packages.python.org/manuel/

> I find it highly unlikely that this
> feature will make it into stdlib.

I agree.

> > and since zope.testing.doctest still reimplements large bits of doctest,
> > I don't know what other bugfixes might be lost too (like the universal
> > newline thing that punishes people for daring to release packages from
> > Windows machines).
> 
> There's no test for that one, so I didn't know about it.

I still don't know anything definite about it, other than remembering
that at some point people on Windows would release .zip sdists with .txt
files inside that had DOS line-endings, and that would cause doctest
failures in some circumstances, again, I'm not sure which.  It was
brought up in another thread recently, and I got the impression that
zope.testing.doctest had a fix of some kind (using universal newlines?).

I suppose we could ignore the issue and wait for some hapless Windows
user to bring it to our attention, at which point we'll fix it and make
sure our fix has a unit test.  Maybe.

*shrug*

> I think the problem with having a sperate doctest.py is evident in the
> fact that there has been bugs fixed for *years* but not moved
> upstream. The custom doctest was there to support Python 3, and
> nothing else. Now it's become it's own creature, and that's very bad.

Yes, I absolutely agree!

> > Overall, I'm still -1 for deprecating zope.testing.doctest at this point.
> > A PendingDeprecationWarning would be more appropriate, IMHO.
> 
> That will just leave less time between people getting warned and
> before it gets removed. I must say I find PendingDeprecationWarnings
> completely and utterly pointless.

Then let's have no warning at all until we have a clear and documented
migration path (and one that doesn't involve loss of features) for
people who use zope.testing.doctest.


tl;dr:

I'm feeling a probably misplaced and crushing sense of responsibility to
make sure existing users of zope.testing and zope.testing.doctest don't
suffer needlessly by the inevitable eventual deprecation and subsequent
removal of zope.testing.doctest.

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3 consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20091230/db927a85/attachment.bin