Mailman 3 February 2005 - pytest-dev

[py-dev] py.test reimporting modules
by Ian Bicking Feb. 23, 2005

Feb. 23, 2005

I'm having some persistent problems with py.test and SQLObject, and collection errors. SQLObject gets confused and angry when a module is imported twice -- for all sorts of good reasons, like two classes with the same name being created. When there are collection errors -- at least some kinds of collection errors -- the module gets imported twice, with the same name and everything. I get this kind of error message: class Reparented1 is already in the registry (other class is <class '/home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py.Reparented1'>, from the module /home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py in /home/ianb/colorstudy.com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta.py; attempted new class is <class '/home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py.Reparented1'>, from the module /home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py in /home/ianb/colorstudy.com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta.py) (Well, I produce the error message, but it's useful information I guess -- the repr() of the class, the cls.__module__, and sys.module[cls.__module__].__file__) I know that collection errors are a known problem, but I thought I'd note this one too. --nomagic doesn't seem to cure it either. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] unit testing error: inconsistenty failed then succeeded
by Felix Schwarz Feb. 20, 2005

Feb. 20, 2005

Hi all, I want to start using pydev for my smaller projects but I get an error that I do not understand. What should "inconsistenty failed then succeeded" tell me? I'm not a native speaker but this sounds strange to me. But beside my problems understanding the error message I don't know why the unit test failes at all. > def test_isLoginAttempt_no(self): > userdata = {'username' : 'foo(a)bar.test', 'password' : 'foobar'} > E login = login.Login(userdata) > ~ (inconsistenty failed then succeeded ) > [C:\Programme\Apache Group\Apache2\vhosts\junkkiller\cgi-bin\Fehler\test_login.p > y:12] > [modulepath: TestLogin.test_isLoginAttempt_no] Minimal testcases attached. Thanks for your help :-) -- Felix

2 2

[py-dev] Type inference documentation wanted
by Valentino Volonghi aka Dialtone Feb. 18, 2005

Feb. 18, 2005

For poor people like me, pypy wannabe contributor, I think it would be good to have some updated documentation about type-inference/annotation as done in pypy. The only doc I can find is heavily outdated, as stated in the first lines of the file. Is this documentation planned? cheers -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.3.8 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de

2 1

[py-dev] py.test test function naming
by Ian Bicking Feb. 17, 2005

Feb. 17, 2005

A note: when I was translating all my SQLObject tests into py.test, one issue I found is that only functions starting in test_ are found, which means functions (or rather methods) like testThis are ignored. This is a problem, because that's the preferred style for unittest, and unittest-based tests are otherwise not too hard to move over (make the sure class name is properly named -- also a bit of a problem -- then get rid of the superclass and turn setUp into setup_method and tearDown into teardown_method). The real problem here is that while other problems with the translation are usually detectable (because a test fails, or syntax is incorrect or something), this problem fails silently, in that a test just gets lost. When converting a big project this is a problem. So that's a long-winded way saying that really any method or function that starts with "test" (no underscore) should be picked up. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] py.path.dict and py.path.proxy patch
by Matthew Scott Feb. 14, 2005

Feb. 14, 2005

Round 2! The attached patch provides the new classes py.path.dict and py.path.proxy, as well as py.__impl__.path.virtual.virtual.Path which is the basis for them. This is an attempt at taking into account some of the suggestions that holger made regarding generalization of the py.path.embed patch I posted in the last couple of days. This patch supersedes the embed1.patch and embed1-1.patch files, so don't use those anymore. What py.path.proxy allows you to do is to take an arbitrary path and create a proxy filesystem into a limited area of that path's filesystem. Maybe a better word would be sandbox, but I found proxy to be easier to type. Naming suggestions are welcome. This code is set in fresh mud, not in stone. :) I haven't yet tried py.path.proxy using anything but py.path.local root paths. Here's an example of using py.path.proxy to wrap a directory specified by py.path.local, and of using py.path.dict to create a dictionary-based virtual file system that contains a copy of that directory: I started IPython in a directory underneath my home directory that contains pictures of a model of laptop that I owned years ago, the Toshiba T1200XE. I created a 'here' variable to contain that path. >>> import py >>> here = py.path.local() >>> here --- local('/home/gldnspud/personal/www/crap/t1200xe') Listing the directory, you can see that it has three files inside it: >>> here.listdir() --- [local('/home/gldnspud/personal/www/crap/t1200xe/1.jpg'), local('/home/gldnspud/personal/www/crap/t1200xe/2.jpg'), local('/home/gldnspud/personal/www/crap/t1200xe/3.jpg')] Now for the fun part. I created a 'prox' variable which is a py.path.proxy whose root is the 'here' path. >>> prox = py.path.proxy(root=here) >>> prox --- proxypath('/', local('/home/gldnspud/personal/www/crap/t1200xe')) If you list its directory, it obviously contains the same files: >>> prox.listdir() --- [proxypath('/1.jpg', local('/home/gldnspud/personal/www/crap/t1200xe')), proxypath('/2.jpg', local('/home/gldnspud/personal/www/crap/t1200xe')), proxypath('/3.jpg', local('/home/gldnspud/personal/www/crap/t1200xe'))] If you traverse to parent directories with 'here', it goes up and up and up. >>> here.join('..', '..') --- local('/home/gldnspud/personal/www') However, if you attempt the same thing using 'prox', you run into the boundary that was defined when prox's virtual filesystem was created. >>> prox.join('..', '..') --- proxypath('/', local('/home/gldnspud/personal/www/crap/t1200xe')) Now I'll create a 'virt' variable which will contain a py.path.dict starting from an empty dictionary. >>> virt = py.path.dict() >>> virt --- dictpath('/', <dict at 4064ed74>) >>> virt.listdir() --- [] I'll populate it with the contents of 'prox'. >>> prox.copy(target=virt) >>> virt.listdir() --- [dictpath('/2.jpg', <dict at 4064ed74>), dictpath('/3.jpg', <dict at 4064ed74>), dictpath('/1.jpg', <dict at 4064ed74>)] What's fun (but maybe pointless other than to show that when it isn't pointless to do so, it can be done) is creating a proxy for a dict path, and then a proxy for that proxy. >>> virt.join('a', 'b', 'c').ensure(dir=True) --- dictpath('/a/b/c', <dict at 4064ed74>) >>> virt.listdir() --- [dictpath('/2.jpg', <dict at 4064ed74>), dictpath('/a', <dict at 4064ed74>), dictpath('/3.jpg', <dict at 4064ed74>), dictpath('/1.jpg', <dict at 4064ed74>)] >>> prox2 = py.path.proxy(root=virt.join('a')) >>> prox2.listdir() --- [proxypath('/b', dictpath('/a', <dict at 4064ed74>))] >>> prox3 = py.path.proxy(root=prox2.join('b')) >>> prox3.listdir() --- [proxypath('/c', proxypath('/b', dictpath('/a', <dict at 4064ed74>)))] Removing the "c" directory in prox3 of course will result in a/b/c being removed from virt. >>> prox3.join('c').remove() >>> virt.join('a', 'b').listdir() --- [] Let's delete the jpg files from virt and create a small text file, and see what the underlying dictionary representation of virt is. (Hint: a 'c' key stands for contents. A directory's contents is a dictionary, and a file's contents is a string). >>> for path in virt.listdir(fil='*.jpg'): path.remove() ... >>> virt.listdir() --- [dictpath('/a', <dict at 4064ed74>)] >>> virt.join('test.txt').ensure().write('hello world') >>> virt.join('test.txt').read() --- 'hello world' >>> virt.fs.dict --- {'c': {'a': {'c': {'b': {'c': {}}}}, 'test.txt': {'c': 'hello world'}}} Fun stuff! - Matthew

2 1

[py-dev] py.test and python 2.2
by Oleg Broytmann Feb. 12, 2005

Feb. 12, 2005

Hello! I'd like to add a minor patch - to use py.test with python 2.2 you need to add "from __future__ import generators" to the beginning of the py/execnet/channel.py. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

2 2

[py-dev] assertions and magic
by Ian Bicking Feb. 9, 2005

Feb. 9, 2005

A little bug: I notice that with magic on py.test doesn't show the message for assertion errors. There's often useful information in those, so it's a shame to throw away that text if it is available, even if you can augment it as well. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

[py-dev] Setup.py for the py library
by Paul Moore Feb. 5, 2005

Feb. 5, 2005

What's involved in creating a setup.py for the py library? I know the install instructions say just to put the dist-py directory on your PYTHONPATH, but I *really* prefer building bdist_wininst installers for everything I use (I'm on Windows) as it makes it so much easier to remember what's installed. I'm guessing that just packaging up the "py" directory/package is most of it. But what about the greenlets stuff? That has its own setup.py, and I don't know how to include that (or indeed if greenlets are needed at all at this point...) Thanks, Paul.

4 8