Hello,
Recently as part of the effort of untangling the tests of ElementTree and
general code improvements (e.g. http://bugs.python.org/issue15651), I ran
into something strange about PEP 3121-compliant modules. I'll demonstrate
with csv, just as an example.
PEP 3121 mandates this function to loo
At least the following 3.4 buildbots have failed today with an error I
do not understand: AMD64 FreeBSD, PPC64, x86Ubuntu, x86 WinServer 2003.
Except for the Windows BB, it was the only failure and hence the only
reason to not be green.
ERROR: test_xmlcharnamereplace (test.test_codeccallbacks.C
On Sat, 10 Aug 2013 20:25:04 -0400
Terry Reedy wrote:
> At least the following 3.4 buildbots have failed today with an error I
> do not understand: AMD64 FreeBSD, PPC64, x86Ubuntu, x86 WinServer 2003.
http://bugs.python.org/issue18706
___
Python-Dev
In a similar vein, Antoine recently noted that the fact the per-module
state isn't a real PyObject creates a variety of interesting lifecycle
management challenges.
I'm not seeing an easy solution, either, except to automatically skip
reinitialization when the module has already been imported.
___
n Sat, Aug 10, 2013 at 5:47 PM, Nick Coghlan wrote:
> In a similar vein, Antoine recently noted that the fact the per-module
> state isn't a real PyObject creates a variety of interesting lifecycle
> management challenges.
>
> I'm not seeing an easy solution, either, except to automatically skip
This run recorded here shows a green test (it appears to have timed out)
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7017
but the corresponding log for this Windows bot
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7017/steps/test/logs/stdio
has the e
