[Python-Dev] Spurious Buildbot Reports
The bots are kicking-off so many false alarms that it is becoming difficult to tell whether a check-in genuinely broke a build. At the root of the problem is a number of tests in the test suite that randomly blow-up. I now tend to automatically dismiss failures in test_logging and test_threading for example. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] integer subclass range behavior
All, I posted this up to comp.lang.python earlier today and asked a few questions around IRC. The general consensus appeared to be that this was a bug. Before opening up an issue on it, I wanted to run it by this list first (just in case) Here is a copy / paste from comp.lang.python: URL: http://groups.google.com/group/comp.lang.python/browse_frm/thread/801f227fceff4066#e0305608a5931af1 Post: I was wondering what would happen, so I tried this out for the heck of it with: Python 3.0a2 (py3k:59572M, Dec 19 2007, 15:54:07) [MSC v.1500 32 bit (Intel)] on win32 class a(int): def __new__(cls,number): return int.__new__(cls,number) for x in range(0,a(5)): print(x) Which resulted in a: Traceback (most recent call last): File "", line 1, in File "a.py", line 5, in for x in range(0,a(5)): SystemError: ..\Objects\longobject.c:400: bad argument to internal function [41030 refs] It looks like the rangeobject performs a FitsInLong test on each of the parameters to range, which uses the function _PyLong_FitsInLong(PyObject *vv) within longobject.c. In tern, this performs a typecheck: #define PyLong_CheckExact(op) (Py_TYPE(op) == &PyLong_Type) that fails. Interesting! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Spurious Buildbot Reports
On Dec 19, 2007 4:33 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The bots are kicking-off so many false alarms that it is becoming difficult > to tell whether a check-in genuinely broke a build. > > At the root of the problem is a number of tests in the test suite that > randomly blow-up. I now tend to automatically dismiss failures in > test_logging and test_threading for example. Yeah, certain tests need some TLC to make them more predictable and less prone to throw a failure because of some touch race condition or something on the machine was not available to make the test work. As I have stated on my blog, once I am done with importlib and the stdlib reorg I plan on working on dev docs and then attack the whole structure of the unit tests. But who knows when that will happen. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Spurious Buildbot Reports
On Wed, Dec 19, 2007 at 05:58:35PM -0800, Brett Cannon wrote: -> On Dec 19, 2007 4:33 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: -> > The bots are kicking-off so many false alarms that it is becoming difficult to tell whether a check-in genuinely broke a build. -> > -> > At the root of the problem is a number of tests in the test suite that randomly blow-up. I now tend to automatically dismiss failures in test_logging and test_threading for example. -> -> Yeah, certain tests need some TLC to make them more predictable and -> less prone to throw a failure because of some touch race condition or -> something on the machine was not available to make the test work. -> -> As I have stated on my blog, once I am done with importlib and the -> stdlib reorg I plan on working on dev docs and then attack the whole -> structure of the unit tests. -> -> But who knows when that will happen. =) OK, but this isn't really a structural problem, right? This is non-determinism in certain tests ;) How broken are these tests? Can we point a 17-yr-old at them and tell them to fix 'em (yes think "GHOP")? (If the problem is reproducible on a 1-in-10 basis then I think the answer is "yes".) And are test_threading and test_logging the two that need the most work? Hmm, perhaps a good starting task would be to run the tests 10-100 times, in random order, on a single machine, to get a statistical picture of of the problem. cheers, --titus (always on the lookout for core => GHOP tasks) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] integer subclass range behavior
Can you submit a bug at bugs.python.org? The minimal example I found: >>> class a(int): pass ... >>> for i in range(0, a(5)): pass ... Traceback (most recent call last): File "", line 1, in SystemError: Objects/longobject.c:400: bad argument to internal function >>> On Dec 19, 2007 5:38 PM, Joseph Armbruster <[EMAIL PROTECTED]> wrote: > All, > > I posted this up to comp.lang.python earlier today and asked a few questions > around IRC. The general consensus appeared to be that this was a bug. Before > opening up an issue on it, I wanted to run it by this list first (just in > case) > Here is a copy / paste from comp.lang.python: > > URL: > > http://groups.google.com/group/comp.lang.python/browse_frm/thread/801f227fceff4066#e0305608a5931af1 > > Post: > > I was wondering what would happen, so I tried this out for the heck of it > with: > Python 3.0a2 (py3k:59572M, Dec 19 2007, 15:54:07) [MSC v.1500 32 bit (Intel)] > on win32 > > class a(int): >def __new__(cls,number): > return int.__new__(cls,number) > > for x in range(0,a(5)): >print(x) > > Which resulted in a: > > Traceback (most recent call last): >File "", line 1, in >File "a.py", line 5, in > for x in range(0,a(5)): > SystemError: ..\Objects\longobject.c:400: bad argument to internal > function > [41030 refs] > > It looks like the rangeobject performs a FitsInLong test on each of > the parameters to range, which uses the function > _PyLong_FitsInLong(PyObject *vv) within longobject.c. In tern, this > performs a typecheck: #define PyLong_CheckExact(op) (Py_TYPE(op) == > &PyLong_Type) that fails. > > Interesting! > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
