Mailman 3 August 2005 - pytest-dev

[py-dev] error building greenlets
by Uche Ogbuji Sept. 6, 2005

Sept. 6, 2005

I can't get greenlets to build on Fedora Core 4 Linux + Python 2.4.1 (or Python 2.3.4. I keep getting the following error. I'm using a pull form Subversion this week. I've tried all sorts of fussing about with the full py library (py/env.py and all that) and all sorts of random tinkering, to no avail. I don't find anything on the error via Google. Any ideas? Traceback (most recent call last): File "test_generator.py", line 1, in ? from py.magic import greenlet File "/home/uogbuji/src/publiccvs/py-dist/py/initpkg.py", line 181, in __getattr__ result = self.__package__._resolve(extpy) File "/home/uogbuji/src/publiccvs/py-dist/py/initpkg.py", line 69, in _resolve implmodule = self._loadimpl(fspath[:-3]) File "/home/uogbuji/src/publiccvs/py-dist/py/initpkg.py", line 99, in _loadimpl return __import__(modpath, None, None, ['__doc__']) File "/home/uogbuji/src/publiccvs/py-dist/py/magic/greenlet.py", line 5, in ? greenlet = path.getpymodule().greenlet File "/home/uogbuji/src/publiccvs/py-dist/py/path/local/local.py", line 408, in getpymodule mod = make_module_from_c(self) File "/home/uogbuji/src/publiccvs/py-dist/py/misc/buildcmodule.py", line 66, in make_module_from_c raise RuntimeError("cannot compile %s: %s\n%s" % (cfile, e, RuntimeError: cannot compile /home/uogbuji/src/publiccvs/py-dist/py/c-extension/greenlet/greenlet.c: error: command 'gcc' failed with exit status 1 /home/uogbuji/src/publiccvs/py-dist/py/c-extension/greenlet/greenlet.c: In function ‘g_switchstack’: /home/uogbuji/src/publiccvs/py-dist/py/c-extension/greenlet/greenlet.c:274: warning: control may reach end of non-void function ‘slp_switch’ being inlined /home/uogbuji/src/publiccvs/py-dist/py/c-extension/greenlet/switch_x86_unix.h:34: error: PIC register ‘ebx’ clobbered in ‘asm’ [1] http://www.xml.com/pub/at/24 -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html

5 9

[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] Greenlet copy
by Alain Poirier Aug. 27, 2005

Aug. 27, 2005

Hi, Do you think it could be possible to add a copy method to the greenlets ? Regards

2 1

[py-dev] Re: [SQLObject] Re: Bug trying to access foreignKey objects for inherited tables. Patch for test attached
by Ian Bicking Aug. 25, 2005

Aug. 25, 2005

Oleg Broytmann wrote: > Hello! I've returned. > > On Thu, Aug 18, 2005 at 12:23:55PM -0300, Evandro Vale Miquelito wrote: > >>Please apply this patch for the test suit and see the problem I got >>using revision 915. > > > I have a stupid problem with py.test - I was running it it with > "python -O" that disabled all assertions! I am so sorry for my stupidity. > Now, when I've fixed the problem I see that you don't need to patch > test_deep_inheritance.py - test_inherited_ForeignKey.py manifests the bug. > > I spend a few hours comparing revision 850 (that works) and the trunk > and finally found the difference (though didn't get the reason). I just > commited a fix that brings inherited ForeignKeys back. Please test if the > revision 944 fixes the problem and does not break anything else. Maybe py.test can test for this case (python -O), since certainly it's no good to run py.test with assertions disabled. Well, I guess you could possibly want to run the tests without assertions; should py.test emit a warning? Maybe just a little something when py.test is started up: try: assert 0 except AssertionError: pass else: print >> sys.stderr, 'Warning: Assertions are turned off! (python -O?)' Just while I'm looking at the code, would it be good in py.tests.cmdline.main(), when exiting with KeyboardInterrupt and verbose off, to do print "KeyboardInterrupt (-v to show traceback)" ? Suggestive error messages and all. I don't know if that assertion test would go in main() or elsewhere. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] Re: [Distutils] setuptools presentation
by Ian Bicking Aug. 12, 2005

Aug. 12, 2005

CC'ing to bring together opposing viewpoints... (this is referring to setuptools' "setup.py test" command, which expects to have a TestSuite to run) Phillip J. Eby wrote: > Also, the 'test' command isn't "limited" to unittest, it > just expects a unittest-compatible wrapper. For example, doctest has > functions that wrap doctests as unittest suites, so it's quite possible > to use that. As far as I'm concerned, unittest suites are the WSGI of > testing; if somebody creates a fancy new test framework, they should > darn well make it possible to put a unittest suite wrapper around it, so > that people can integrate their existing tests. :) Well, I don't know what exactly my opinion is. At a py.test user I don't have TestSuites for my tests. I've argued py.test should load TestCase-based tests by default, but this is kind of the opposite. I don't think it would be that hard to produce such suites; the test items that py.test collects could just be stuffed into a TestCase. The result would be acceptable as a sort of "this package thinks it runs okay" test. It's not the frontend I'd like to give to users. That said, if "python setup.py test ..." was completely equivalent to "py.test ..." then that would be great, because though the interface would be different from projects that use unittest, the entry point would be the same (assuming py.test is installed). I suppose a package could add an entry point that overrides the normal setuptools test command...? -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

4 5

[py-dev] PYTHONPATH not being honored
by Sean Dawson Aug. 11, 2005

Aug. 11, 2005

Hello, I'm getting funky errors trying to set PYTHONPATH to override libraries. Consider the following example: $ cd sandbox $ mkdir trac $ touch trac/__init__.py $ vim test_pypath.py inside this file I just write: --- import trac print trac.__file__ assert 1==2 --- Note: I have a trac library installed in my site-packages directory. Running py.test in the sandbox directory gives the result I would expect, that is, it correctly imports the trac folder located in my sandbox dir. However, I'm experiencing problems when I do the following: $ mkdir blah $ mv trac blah/trac $ PYTHONPATH=blah py.test In this case, however, the print statement tells me the trac library from my site-packages is getting loaded. Any ideas? I am running py.dist trunk Thanks, Sean

1 0