[Zope-dev] whitespace filtering corner case in doctest

[Marius Gedminas]

On Tue, Aug 18, 2009 at 08:53:49AM +0000, Reinout van Rees wrote:
> On 2009-08-17, Marius Gedminas <marius at gedmin.as> wrote:
> >
> > On Mon, Aug 17, 2009 at 02:46:46PM +0000, Reinout van Rees wrote:
> >> In some cases, importing readline can result in the escape code
> >> ^[[?1034h= to be send ("8bit on").
> >
> > According to the gentoo bug report (liked from your blog post), this
> > happens if your termcap/terminfo define smm/rmm codes ("meta on/meta
> > off").
> 
> ... which I didn't do, at least not consiously.  Just a pretty normal
> OSX installation.
> 
> > BTW, regarding your workaround: I'd suggest using TERM=3Ddummy instead of
> > TERM=3Dlinux, as a safer choice.  Not that it should matter much in
> > practice.
> 
> That'd be better, yes.  I never do anything tweaking with TERM anyway,
> so I don't know the options/effects.
> 
> jladage suggested to do the workaround in buildout, btw: add the
> following to the part that generates the bin/test script:
> 
>  environment-vars =
>      TERM linux
> 
> >> This escape code isn't visible, which leads to hard to find test
> >> errors, see
> >> http://reinout.vanrees.org/weblog/2009/07/16/invisible-test-diff.html
> >> Granted, it are basically corner cases.  On the other hand, it does
> >> seem to cause problems now and then, according= > to my googling.
> >> Would it be ok to add it to the whitespace normalization of
> >> doctests?  Opinions?
> >
> > Well, it's not whitespace, really...  My gut feeling is that this fixup
> > doesn't belong in the core doctest code.
> 
> Ok.
> 
> > If this happened in my project, I'd either
> >
> >   1) make sure I import readline at module level, before any tests are
> >      run
> 
> This doesn't work, surprisingly.  It *is* a corner case.
> It are tests where z3c.testsetup tests that it runs tests correctly.
> That's a lot of "tests" in one sentence, which means that the test
> output comes from separate python processes that run tests.  So if I
> import readline in z3c.testsetup's tests, I still get the output from
> the test runners that are being tested.
> 
> Sigh, difficult to explain, such a recusive testing thingy :-)

Sounds perfectly clear to me.  I once tried to make sure zope.testing's tests
covered the test coverage code, and measuring the coverage of the tests
testing coverage measurement turned out to be impossible.

> > or
> >
> >   2) add a renormalizer that removes the escape sequence for the test
> >      that triggers this
> 
> And you'd do this per-project and not in core zope.testing, right?
> Fine.  Uli already send me some example code, so I'll do that (and put
> the code snippet on my weblog so that google can find it).
> 
> > Perhaps it would be nice if doctest's differ escaped ASCII control
> > characters?  (You could do that too with a renormalizer.)
> 
> Can we safely assume that a specific set of control characters needs
> to be escaped?  It sounds a bit dangerous to me.

ASCII and defines which characters are printable and which ones are
control characters.  Maybe \x9b poses a bit of a problem, since it's an
escape character for some terminals, but a real character on some legacy
8bit charsets.  (It's not allowed in UTF-8 sequences.)

Or perhaps you mean it may make it difficult to distinguish a test
printing \x1b from a test printing ^ followed by [ (assuming that's the
visualisation chosen for control characters).  That is an issue.

BTW I've no clue why I'm replying to a month-old post.  I missed it
earlier somehow.

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/20090916/3caf75ea/attachment-0001.bin