[Python-Dev] status of development documentation

Neal Norwitz nnorwitz at gmail.com
Sat Dec 24 08:14:48 CET 2005


On 12/23/05, Tim Peters <tim.peters at gmail.com> wrote:
> >
> >     http://docs.python.org/dev/results/
>
> Wow!  You get no test failures!  I guess nobody tests on Windows
> anymore.  I've been getting test failures for months, and just

Hmmm, I thought others were running the tests on Windows too.  There
was one report on Nov 22 about running Purify on Windows 2k (subject:
ast status, memory leaks, etc).  He had problems with a stack overflow
in test_compile.  He was going to disable the test and re-run.  I
never heard back though.  Based on that info, I would guess that
test_builtin was working on Win 2k on Nov 22.

> _assumed_ this was known damage everywhere so was waiting for someone
> else to fix it ;-)  (A parenthentical question:  is there a reason you
> don't pass -uall to regrtest.py?)

It's calling make test.  I thought about calling regrtest.py instead
and doing as you suggest.  Is there a benefit to running make test?  I
know it runs with and without -O.  I guess it's only machine time, I
could run make test and regrtest.py -uall.

> On WinXP Pro SP2 today, passing -uall, and after fixing all the MS
> compiler warnings that have crept in:
>
> 251 tests OK.
> 12 tests failed:
>     test_builtin test_coding test_compiler test_pep263
>     test_univnewlines test_urllib test_urllib2 test_urllibnet
>     test_userlist test_wave test_whichdb test_zipfile
> 1 skip unexpected on win32:
>     test_xml_etree_c

Ouch!  I'm might be to blame for at least some of those. :-(

> ERROR: test_compile (test.test_builtin.BuiltinTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "C:\Code\python\lib\test\test_builtin.py", line 237, in test_compile
>     compile(bom + 'print 1\n', '', 'exec')
>   File "<string>", line 1
>     ¡É¨[©´print 1
>     ^
> SyntaxError: invalid syntax

> I have no idea what those are trying to test, and remember guessing
> the first time I saw this that it was fallout from the AST-branch
> merge.  Apparently it wasn't :-(.  Anyone have a clue on this one?

This test code was added a while ago by Just.  So the test code isn't new.
I changed some compile code wrt unicode that was a memory leak (r41553).
I just ran valgrind and it didn't report any problems.  So I don't
think that change broke Windows.

Do you know if the tests were broken before the AST merge (about Oct
22 I think)?

> The code up to the first failure is short:
>
>         bom = '\xef\xbb\xbf'
>         compile(bom + 'print 1\n', '', 'exec')
>
> Curiously, that sequence doesn't blow up under the released Windows
> Python 2.4.2, so somebody broke something here since then ...

There were a bunch of changes to Parser/tokenizer.c to handle error
conditions.  Those go back to Oct 1.  I don't *think* those would
cause these, but I'm not sure.

Sorry, I don't know any more.  I guess you might have to binary search
by date to try and find the problem.

n


More information about the Python-Dev mailing list