Mailman 3 May 2005 - pytest-dev

[py-dev] greenlet.main_greenlet
by Tom Locke Aug. 27, 2005

Aug. 27, 2005

Hi, I had a need to be able to test if the current greenlet was the main greenlet. I figured this might be something that crops up now and again, so I added a module attribute `main_greeenlet` (also copied to the type object), so I can just test for: greenlet.getcurrent() == greenlet.main_greenlet There's two small changes to greenlet.c (see diff) Tom Index: greenlet.c =================================================================== --- greenlet.c (revision 12401) +++ greenlet.c (working copy) @@ -758,7 +758,7 @@ }; static char* copy_on_greentype[] = { - "getcurrent", "error", "GreenletExit", NULL + "getcurrent", "error", "GreenletExit", "main_greenlet", NULL }; void initgreenlet(void) @@ -787,6 +787,8 @@ if (ts_current == NULL) return; + Py_INCREF(ts_current); + PyModule_AddObject(m, "main_greenlet", (PyObject*)ts_current); Py_INCREF(&PyGreen_Type); PyModule_AddObject(m, "greenlet", (PyObject*) &PyGreen_Type); Py_INCREF(PyExc_GreenletError);

2 1

[py-dev] Idea: pluggable comparison summaries
by Ian Bicking May 25, 2005

May 25, 2005

It occurs to me that it would be nice to be able to plug different outputs/reports into the system, when encountering the idiomic form "x == y" (or !=). For instance, one might use diff format when the strings above a certain length. Or for large dictionaries, you might summarize differences (e.g. "x is missing key 'foo'", or "x['foo'] != y['foo']", etc. I imagine these would be enabled in conftest.py somehow, and there'd be some list of them where each one could return a report or defer (maybe returning None). I imagine there could be some nice hooks into the tk frontend at some point too, where you can display the data in some GUI-specific way. There should be room in the API for that somehow (though the tk frontend should degrade to showing strings for non-GUI-aware comparisons). -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

[py-dev] greenlet.main_greenlet
by Tom Locke May 23, 2005

May 23, 2005

Hi, I had a need to be able to test if the current greenlet was the main greenlet. I figured this might be something that crops up now and again, so I added a module attribute `main_greeenlet` (also copied to the type object), so I can just test for: greenlet.getcurrent() == greenlet.main_greenlet There's two small changes to greenlet.c (see diff) Tom Index: greenlet.c =================================================================== --- greenlet.c (revision 12401) +++ greenlet.c (working copy) @@ -758,7 +758,7 @@ }; static char* copy_on_greentype[] = { - "getcurrent", "error", "GreenletExit", NULL + "getcurrent", "error", "GreenletExit", "main_greenlet", NULL }; void initgreenlet(void) @@ -787,6 +787,8 @@ if (ts_current == NULL) return; + Py_INCREF(ts_current); + PyModule_AddObject(m, "main_greenlet", (PyObject*)ts_current); Py_INCREF(&PyGreen_Type); PyModule_AddObject(m, "greenlet", (PyObject*) &PyGreen_Type); Py_INCREF(PyExc_GreenletError);

2 2

[py-dev] greenlet problems (followup)
by Moe A May 18, 2005

May 18, 2005

sorry, i neglected to give additional information. im running dual x86, and here is the backtrace from the core file: #0 0x284a35e6 in g_switchstack () from /usr/local/lib/python2.4/site-packages/greenlet.so #1 0x284a3831 in g_initialstub () from /usr/local/lib/python2.4/site-packages/greenlet.so #2 0x284a36ff in g_switch () from /usr/local/lib/python2.4/site-packages/greenlet.so #3 0x284a3d74 in green_switch () from /usr/local/lib/python2.4/site-packages/greenlet.so #4 0x080d59ed in PyCFunction_Call () #5 0x08059fe0 in PyObject_Call () #6 0x0809f7b9 in PyEval_GetFuncDesc () #7 0x0809d21c in PyEval_EvalFrame () #8 0x0809dfdb in PyEval_EvalCodeEx () #9 0x0809f332 in PyEval_GetFuncDesc () #10 0x0809f1a4 in PyEval_GetFuncDesc () #11 0x0809d16c in PyEval_EvalFrame () #12 0x0809dfdb in PyEval_EvalCodeEx () #13 0x0809ab02 in PyEval_EvalCode () #14 0x080b8d3c in PyRun_FileExFlags () #15 0x080b8cf7 in PyRun_FileExFlags () #16 0x080b8cc1 in PyRun_FileExFlags () #17 0x080b7f8b in PyRun_SimpleFileExFlags () #18 0x080b79d2 in PyRun_AnyFileExFlags () #19 0x08054f36 in Py_Main () #20 0x0805468a in main () #21 0x08054582 in _start ()

1 0

[py-dev] greenlet problems!
by Moe A May 18, 2005

May 18, 2005

i ran the distutils setup scripts for both Py and the separate one for greenlets. i copied and pasted the following example from codespeak.net, but it segfaults after printing "hello world" ( "zsh: segmentation fault (core dumped) python green.py"). i'm running FreeBSD 5.2.1. from py.magic import greenlet def test1(x, y): z = gr2.switch(x+y) print z def test2(u): print u gr1.switch(42) gr1 = greenlet(test1) gr2 = greenlet(test2) gr1.switch("hello", " world")

2 1

[py-dev] Bug in assert statement
by Ian Bicking May 16, 2005

May 16, 2005

When you do something like: assert 0, dir(module) You get an exception from the assert reinterpretation. Asserting with a non-string message normally works fine. I've also noticed a problem when your assert statement contains an object who's __repr__ returns a string with a newline in it. I've put a test in the repository at http://codespeak.net/svn/user/ianb/py_test_assert_failure/test_asserts.py -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] Catching KeyboardInterrupt
by Ian Bicking May 16, 2005

May 16, 2005

It would be nice if py.test didn't so cleanly exit from a KeyboardInterrupt -- right now I'm encountering a test that hangs, which I usually figure out by ^C'ing and seeing what the traceback says. At least, that's what I've become used to doing. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] Python Paste testing and py.test
by Ian Bicking May 15, 2005

May 15, 2005

You guys might be interested in this description of using py.test and Paste to test applications: http://pythonpaste.org/docs/testing-applications.html In the end the code behind it is fairly simple, but it seems to work well enough. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

[py-dev] py.test exit code 0 even on failure
by Michael Twomey May 14, 2005

May 14, 2005

Hi, I've been plugging py.test into darc's automatic test features and I've found that py.test doesn't appear to exit with anything other than a 0, even when there are failures. This means that darcs won't notice that there were test failures on my commits. I haven't verified that this is the case on anything other than my mac. The following patch makes py.test exit with a 1 when there are problems (or at least a list of stuff returned by main). This works for me, though I'm sure there is a better spot/way to do this. cheers, mick

2 1

[py-dev] Backtracking on doctest
by Ian Bicking May 14, 2005

May 14, 2005

Well, now I'm starting to backtrack. After I extended my test while adding new features, I looked back over my doctests and realized they were pretty pointless. For brevity, most of my code no longer produced output at all, but instead was doing internal inserts. If I didn't have a wrapper around my application for testing this might not have been feasible, but without a wrapper the testing wouldn't be feasible. Anyway, I converted it to a normal py.test test. It seems much more reasonable. I'm a little sad that it's not sitting right next to the servlet that it tests -- I liked that the tests were in a docstring (though they were also becoming rather long-winded, so maybe that's not ultimately practical either). And I also found myself wanting features like the assert reinterpretation, which I lost in doctests. setup_module turned out to be quite useful; I added this to my conftest, and do a "from conftest import setup_module" in my module: def setup_module(module): app = TestApp(server.make_app(CONFIG.current_conf()), CONFIG.current_conf()) module.app = app module.CONFIG = CONFIG fixture.reset_state() I think it's likely that other boilerplate stuff will go in there in the future. I'd still like doctests to work nicely, but it becomes less important to me. Anyway, no requests here, just thought I'd share my current and always changing thoughts on the matter. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

3 3