Mailman 3 December 2004 - pytest-dev

[py-dev] Problems with DOS files
by Yaroslav Bulatov Jan. 19, 2005

Jan. 19, 2005

py.test runs into problems with files using DOS linebreaks (ie \r\n) under Cygwin When I run py.test on a file with DOS linebreaks I get something like def test_5(): ^ SyntaxError: invalid syntax On other hand, when I run the same file using the same python executable, it reports no error. $ /usr/bin/python2.3 test_maxent_classifier.py Traceback (most recent call last): File "test_maxent_classifier.py", line 4, in ? if __name__=='__main__': test_5() File "test_maxent_classifier.py", line 2, in test_5 assert 1==2 AssertionError $ py.test============================= test process starts ============================= testing-mode: inprocess executable : /usr/bin/python2.3 (2.3.4-final-0) =============================================================================== C.. _______________________________________________________________________________ ________________________________ Collect Error ________________________________ def getpycodeobj(self): dotpy = self.check(ext='.py') if dotpy: my_magic = py.std.imp.get_magic() my_timestamp = int(self.mtime()) if __debug__: pycfile = self + 'c' else: pycfile = self + 'o' try: f = pycfile.open('rb') try: header = f.read(8) if len(header) == 8: magic, timestamp = py.std.struct.unpack('<4si', header) if magic == my_magic and timestamp == my_timestamp: return py.std.marshal.load(f) finally: f.close() except IOError: pass s = self.read() > codeobj = compile(s, str(self), 'exec') > /cygdrive/c/Python23/Lib/site-packages/dist-py/py/path/local/local.py, line 36 0 File "/cygdrive/g/research/maxent/classifier/test_maxent_classifier.py", line 1 def test_5(): ^ SyntaxError: invalid syntax ================== tests finished: 2 passed in 0.05 seconds ================== On other hand, everything works fine if I convert the files to unix mode

13 25

[py-dev] getstatementrange() broken?
by Krzysztof Kowalczyk Dec. 31, 2004

Dec. 31, 2004

I'm just starting with py.test so I wrote a trivial program test_foo.py: def test_fail(): # failing test assert 1 == 2 def test_ok(): assert 1 == 1 When I run it with py.test, instead of getting a nice callstack for test_fail() failing assert, I get a long callstack for py.test itself. The problem comes from \py\code\source.py getstatementrange(). Now, I know nothing about py.test but the code there is just weird, e.g.: for end in range(lineno, len(self)): trysource = self[lineno:end+1] if trysource.isparseable(): start = lineno break else: end = lineno I guess I don't know python as well as I thought, but how an "else" to a "for" is even possible? Specifically, the problem comes from the fact, that at some point there is: else: return None and the caller: def getstatement(self, lineno): """ return Source statement which contains the given linenumber (counted from 0). """ > start, end = self.getstatementrange(lineno) doesn't handle that. It must get a sequence. Anyway, things seem to work when I replace the function with just: return lineno, lineno+1 Of course, this is bogus and won't work if lineno is at the end of the file, so someone who knows what's going on in getstatementrange() should take a look. I'm using latest svn sources. Happy New Year to everyone. Krzysztof Kowalczyk : http://blog.kowalczyk.info Here's a full callstack: C:\kjk\src\mine\moriarty_palm\tests>python c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\bin\py.test ============================= test process starts ============================= testing-mode: inprocess executable : c:\Python24\python.exe (2.4.0-final-0) using py lib: c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py <rev 8008> initial testconfig 0: c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\test\defaultconfig =============================================================================== F. _______________________________________________________________________________ def runitem(self, item): if not self.option.collectonly: self.reporter.startitem(item) try: > item.run(self) [c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\test\drive.py:92] ------------------------------------------------------------------------------- def run(self, driver): self.setupmanager.setup_path(self.extpy) target, teardown = self.setupmanager.setup_method(self.extpy) try: > self.execute(target, *self.args) [c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\test\item.py:78] ------------------------------------------------------------------------------- def execute(self, target, *args): """ default implementation for calling a test target is to simply call it. """ > target(*args) [c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\test\item.py:87] ------------------------------------------------------------------------------- def __init__(self, *args): BuiltinAssertionError.__init__(self, *args) f = sys._getframe(1) try: > source = py.code.Frame(f).statement [c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\magic\assertion.py:12] ------------------------------------------------------------------------------- def statement(self): > return self.code.fullsource.getstatement(self.lineno) [c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\code\frame.py:35] ------------------------------------------------------------------------------- def getstatement(self, lineno): """ return Source statement which contains the given linenumber (counted from 0). """ > start, end = self.getstatementrange(lineno) [c:\kjk\src\mine\moriarty_palm\scripts\dist-py\py\code\source.py:62] ------------------------------------------------------------------------------- (reinterpretation failed, you may increase verbosity to see details) TypeError: unpack non-sequence ============= tests finished: 1 passed, 1 failed in 0.02 seconds =============

2 2

[py-dev] move tests into their own directory ...
by Laura Creighton Dec. 24, 2004

Dec. 24, 2004

For what it's worth, I think it is a very good idea. Laura

4 4

[py-dev] revision 7936 makes it harder to see failing source compiled from a string
by Matthew Scott Dec. 22, 2004

Dec. 22, 2004

Love py.test! :) But for now, I find that I am going to revert to revision 7935 and stay at that for a little while 'til the dust settles. Here's why. Take this test which canonically distills the problem: # test_7935_vs_7936.py import imp from py.magic.dyncode import compile import sys def test_it(): src = 'def foo():\n assert 1 == 0\n' name = 'abc-123' module = imp.new_module(name) code = compile(src, name, 'exec') exec code in module.__dict__ sys.modules[name] = module module.foo() If you run it against revision 7936 or higher, you get the following error as the cause of the failure: > /home/gldnspud/p/open/py-dist/py/path/local/local.py, line 516 ------------------------------------------------------------------------------- IOError: << [Errno 2] No such file or directory: '/home/gldnspud/</home/gldnspud/test_7935_vs_7936.py:9>' However, if you use revision 7935, you get this instead: > </home/gldnspud/test_7935_vs_7936.py:9>, line 2 ------------------------------------------------------------------------------- assert 1 == 0 This seems to be happening because the code that is actually raising the exception is inside a module whose code is created using py.magic.dyncode.compile, using a string as the source. I know this isn't common usage of Python, but it is a cornerstone of a project that I'm working on at the moment :) Any ideas on how to work around this? Or could py be changed somehow to accommodate this type of module? Happy with 7935 for now though :) Thanks for the excellent framework! - Matthew

3 2

[py-dev] How do I access current testing directory?
by Kevin Smith Dec. 22, 2004

Dec. 22, 2004

Great great testing program. What a time saver, very pythonic. My question is how do I access the current working directory (where the test is located) from within the test? Kev

2 1

[py-dev] Greenlets
by Florian Schulze Dec. 19, 2004

Dec. 19, 2004

Hi! I just saw that greenlets where imported into py and I wanted to try them out. Unfortunately they don't compile on windows, the offending line is #536: PyObject_HEAD_INIT(&PyType_Type) greenlet.c(536) : error C2099: Initialisierung ist keine Konstante roughly translated: greenlet.c(536) : error C2099: Initializer is not constant I looked into other extension modules and there all those lines read like this: PyObject_HEAD_INIT(NULL) It compiled with that line, but it crashes after the greenlets ran through. It's an really interesting idea though. Regards, Florian Schulze ps: Are Armin Rigo and Christian Tismer on this list?

4 5

[py-dev] changes ahead ...
by hpk＠trillke.net Dec. 16, 2004

Dec. 16, 2004

hi py-dev, just a short warning note that in the upcoming days there are going to be quite some changes to py.test. There is no explicit plan to break it but you'll never know :-) Basically we are going to try to port PyPy's tests to py.test and expand some of the capabilities of py.test for this. cheers, holger

1 0

[py-dev] .py files without trailing newlines
by Ian Bicking Dec. 9, 2004

Dec. 9, 2004

Just noticed that I get a syntax error if I load a Python file (with extpy) that doesn't have a trailing newline. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] rootdir and --session
by Ian Bicking Dec. 9, 2004

Dec. 9, 2004

When I run py.test --session I get an error (and perhaps because that's the only option that requires configuration?): Traceback (most recent call last): File "/home/ianb/py/dist/py/bin/py.test", line 5, in ? main() File "/home/ianb/py/dist/py/test/cmdline.py", line 29, in main run.session(args, filenames) File "/home/ianb/py/dist/py/test/run.py", line 174, in session rootdir = py.path.local(py.test.config.getfirst('rootdir')) File "/home/ianb/py/dist/py/test/config.py", line 50, in getfirst raise AttributeError, param AttributeError: rootdir The only place it seems to be looking for configuration is py/test/defaultconfig.py, and it's not clear how I add other files. And should rootdir be a command-line option (default '.')? -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

[py-dev] Re: [py-svn] r7784 - in py/dist/py: . test
by hpk＠trillke.net Dec. 8, 2004

Dec. 8, 2004

Hi Ian, hi All, i have implemented generative tests: > New Revision: 7784 > implemented support for Generator (collection) functions and methods. > plus a couple of tests. > > With this new hack you can yield parametrized tests in an easy > ("the best API is one that doesn't exist") way: > > def somefunc(x, y): > assert x * y == 42 > > def test_generator(): > yield somefunc, 6, 7 > yield somefunc, 7, 6 However, i am not completly sure yet about appropriate setup/teardown semantics. Should setup_method()/teardown_method() be performed for each run of a generated callable+*args/**kwargs thingie or just for the test generator itself? (test generator = the test function that actually yields callables/args/kwargs tuples). cheers, holger

1 0