Mailman 3 July 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] tkinter tests failing after capture changes
by hpk＠trillke.net July 31, 2005

July 31, 2005

Hi Jan, it appears that at least on my linux machine two tkinter related tests are failing after the recent IO-capturing changes (we are now doing capturing on FD-level as well as on sys.stdout/stderr level). I couldn't figure out so far what the actual problem is. Can you have a look? The two failing tests are (i guess you will get them as well): py/test/tkinter/testing/test_capture_out_err.py:16 py/test/tkinter/testing/test_backend.py:188 cheers & thanks, holger

3 2

[py-dev] Re: [py-svn] r15385 - in py/dist/py: . io io/test test test/terminal test/testing thread/testing
by Brian Dorsey July 29, 2005

July 29, 2005

On 29/07/05, hpk(a)codespeak.net <hpk(a)codespeak.net> wrote: > py.test now uses py.io.OutErrCapture to capture > stdout/stderr and should be a bit more robust. > We can easily switch back to the old more shallow > way of stdout/stderr capturing (which just patched > sys.stdout and sys.stderr) should there be a need. > > the py.io-interface is likely to get refined > a bit over time so use with some care. > > i am interested to hear especially if there > are problems on win32 regarding running py.test. It seems to work for me. All I did was verify that my tests still run, and that when I introduce a failure, I still see output from 'print', but that much at least works. Take care, -Brian

1 0

[py-dev] Using py.test with PyQt
by Matthew Scott July 29, 2005

July 29, 2005

I currently have a need to write some unit tests for some custom PyQt widgets, so I put together a base class for py.test based unit tests and a corresponding QApplication subclass. The code is available here if anyone would like to use it: http://svn.orbtech.com/cgi-bin/schevo.cgi/file/branches/rebel/schevo_qt/tes… Tests that may also serve as additional documentation are available here: http://svn.orbtech.com/cgi-bin/schevo.cgi/file/branches/rebel/schevo_qt/tes… It's pretty simple right now, but I'll probably take a closer look at something like http://pyguiunit.sourceforge.net/ and implement some helper functions like click(), typeText(), and so forth. Feedback welcome and appreciated... -- Matthew R. Scott

2 1

[py-dev] Really simple question about py.test
by Sean Leach July 28, 2005

July 28, 2005

Why does this execute the same test twice (it only happens on a failed test): % cat test_twice.py def fail(): print 'running failed' return False class TestTwice: def test_twice(self): assert fail() % py.test test_twice.py It will print 'running failed' twice (and of course run fail() twice). Is this a feature I am missing in the docs? I really don't want my failed tests to run twice. I am using the latest svn code. Regards, Sean

2 2

Re: [py-dev] py.log -- annotating logs
by Ian Bicking July 27, 2005

July 27, 2005

I'm guessing you meant to copy the list... Grig Gheorghiu wrote: > Maybe the easiest way would be to just define a consumer per > "application domain", i.e. for your Web app you'd have a > web_app_consumer() function that would know how to print all the info > you need. > > The way it works right now is that you need to associate a consumer > with one or more keywords. Then you have the flexibility of changing > consumers for those keywords dynamically via configuration files etc. > > So I'd do something like this in a configuration file: > > log = py.log.Producer("mywebapp") > def my_consumer(message): > remote_ip = get_current_remote_ip() > crt_time = get_current_time() > message.args = [crt_time, remote_ip] + message.args > print str(message) # prints "[mywebapp] crt_time remote_ip > <rest_of_message>" This particular example doesn't work well with other consumers. I'd want to change the message and then let another consumer deal with that message. Unfortunately this kind of composition through dispatching is very configuration-unfriendly -- that's something we're hitting with WSGI middleware configuration right now. But what makes it unfriendly is also what makes it very flexible. The wrapping consumer I gave before could, potentially, be inserted in a number of places. It could be put in place globally, or for a single keyword, or whatever. This presumes, of course, that it's possible to find consumers without running them, so a new consumer can be inserted instead of just overwriting the old one. This can be challenging in itself. There might be one root consumer. Let's say by default it's the consumer that dispatches based on keyword. If we try to insert another consumer in the root consumer, and the dispatching consumer has been replaced, the replacement doesn't necessarily have the same API. Should that replacement consumer send all unknown attributes to its sub-consumer? But the keyword dispatching consumer doesn't have a single sub-consumer to dispatch to, so that doesn't work there. And other dispatchers are also possible -- for instance, this application supports multiple clients, and if a client is associated with a request I'd like to put the log file in a location specific to that client. But that's more programmatic than keywords, and I can create the sub-consumers dynamically. Or maybe some component is generating annoying log messages, and I want to filter them out based on some really arbitrary expression. There's lots of possibilities. But the setup can become hard. But then, it's clear that the logging module doesn't have easy setup either. > py.log.set_consumer("mywebapp", my_consumer) > > Then you would just use log(message) in your code. > > Does this help or maybe I'm way off the mark? -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] py.log -- annotating logs
by Ian Bicking July 27, 2005

July 27, 2005

I haven't actually used py.log yet, but was just doing logging in another context, and I'm curious if py.log solves the problem, or if it could be made to do so. Specifically, I want to add contextual information to all my logging. In a web app that might be the remote IP address, session ID, or username. Other environments usually have other context. The actual information would probably live in threadlocal storage. Looking at Grig's blog post, one way would be with a consumer that wraps another consumer. But this seems like it would lead to potentially complex consumer composition, especially since there's a number of things that are possibly being pushed into consumers. Maybe that's not so bad -- I personally am inclined toward that kind of composition anyway. Really py.log could just be thin wrapper around record objects, where everything is dispatched to a single consumer. Like maybe I'd do: def add_remote_ip(old_consumer): def new_consumer(message): message.remote_ip = get_current_remote_ip() message.format = '[%(keywords)s] %(time)s %(remote_ip)s %(message)s' return old_consumer(message) return new_consumer py.log.set_consumer(annotate_consumer(py.log.get_consumer())) message.format looks a little fragile, though. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

[py-dev] py.test error with cygwin update
by odonian＠gmail.com July 20, 2005

July 20, 2005

I've been happily using py.test for about two months without problems with an older version of cygwin (maybe 3-4 months old; sorry, don't have the version number) and python 2.3.4. Just recently I updated the cygwin environment, and now py.test keeps failing; I have tried re-installing the py lib, re-installing cygwin, and tried different versions of python (2.3.4, 2.4.1). But this error keeps coming up when running py.test, regardless of any other command-line arguments (i.e. whether it's run in test collection mode, or fed a specific test file, this error shows up): Traceback (most recent call last): File "/usr/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/lib/python2.4/site-packages/py/test/cmdline.py", line 8, in main config, args = py.test.Config.parse(py.std.sys.argv[1:]) File "/usr/lib/python2.4/site-packages/py/test/config.py", line 60, in parse configpaths = guessconfigpaths(*getanchorpaths(args)) File "/usr/lib/python2.4/site-packages/py/test/config.py", line 183, in guessconfigpaths if x.check(file=1): File "/usr/lib/python2.4/site-packages/py/path/common.py", line 96, in check return self.Checkers(self)._evaluate(kw) File "/usr/lib/python2.4/site-packages/py/path/common.py", line 69, in _evaluate if bool(value) ^ bool(meth()) ^ invert: File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 38, in file return stat.S_ISREG(self._stat().st_mode) File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 29, in _stat self._statcache = self.path.stat() File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 283, in stat return self._callex(os.stat, self.strpath) File "/usr/lib/python2.4/site-packages/py/path/common.py", line 207, in _callex cls = py.error._geterrnoclass(errno) File "/usr/lib/python2.4/site-packages/py/misc/error.py", line 45, in _geterrnoclass clsname = py.std.errno.errorcode[eno] KeyError: 136 Since this didn't show up before, ever, I'm guessing paths are somehow handled differently in newer cygwin versions, but hard to imagine why it would change that much. I have tried catching the above particular KeyError for the errorcode dictionary, but that only causes another problem elsewhere. Any help would be appreciated, S.A.

4 9

[py-dev] svn diff for producer.py and consumer.py
by Grig Gheorghiu July 18, 2005

July 18, 2005

Holger, I'm including 2 diffs for consumer.py and producer.py. I added some initial unicode support, with a default encoding of 'utf-8'. The only other modification is that the prefix() method of a Message only uses square brackets when there are actual keywords to be printed. If you instantiate a log object via log = py.log.Producer(""), then log('blah') will now produce 'blah', not '[] blah'. I didn't want to commit these changes, since you may have other ideas on the unicode stuff. Grig # svn diff producer.py Index: producer.py =================================================================== --- producer.py (revision 14743) +++ producer.py (working copy) @@ -16,14 +16,20 @@ self.args = args def content(self): - return " ".join(map(str, self.args)) + return " ".join(map(unicode, self.args)) - def prefix(self): - return "[%s] " % (":".join(self.keywords)) + def prefix(self): + if not self.keywords: + return u"" + return "[%s] " % (u":".join(self.keywords)) def __str__(self): - return self.prefix() + self.content() + s = self.prefix() + self.content() + return s.encode('utf-8') + def __unicode__(self): + return self.prefix() + self.content() + class Producer(object): """ Log producer API which sends messages to be logged to a 'consumer' object, which then prints them to stdout, @@ -71,6 +77,6 @@ Producer.keywords2consumer.update(state) def default_consumer(msg): - print str(msg) + print unicode(msg).encode('utf-8') Producer.keywords2consumer['default'] = default_consumer # svn diff consumer.py Index: consumer.py =================================================================== --- consumer.py (revision 14743) +++ consumer.py (working copy) @@ -1,6 +1,8 @@ import py import sys +DEFAULT_ENCODING = 'utf-8' + class File(object): def __init__(self, f): assert hasattr(f, 'write') @@ -8,7 +10,7 @@ self._file = f def __call__(self, msg): - print >>self._file, str(msg) + print >>self._file, unicode(msg).encode(DEFAULT_ENCODING) class Path(File): def __init__(self, filename, append=False): @@ -17,10 +19,10 @@ super(Path, self).__init__(f) def STDOUT(msg): - print >>sys.stdout, str(msg) + print >>sys.stdout, unicode(msg).encode(DEFAULT_ENCODING) def STDERR(msg): - print >>sys.stderr, str(msg) + print >>sys.stderr, unicode(msg).encode(DEFAULT_ENCODING) def setconsumer(keywords, consumer): # normalize to tuples

1 0

Re: [py-dev] Running only previously failing tests
by Grig Gheorghiu July 18, 2005

July 18, 2005

--- holger krekel <hpk(a)trillke.net> wrote: > On Mon, Jul 18, 2005 at 10:57 -0700, Grig Gheorghiu wrote: > > --- holger krekel <hpk(a)trillke.net> wrote: > > > > > Hi Grig! > > > > > > On Mon, Jul 18, 2005 at 10:33 -0700, Grig Gheorghiu wrote: > > > > I thought this was possible via 'py.test --session=terminal' > for > > > > example, but when I do that all the tests are run, not only the > > > ones > > > > that were previously failing. Am I doing something wrong? > > > > > > Only the '--looponfailing' option does what you want. It keeps > > > the frontend process looping and waiting for file changes > > > in the project. On such changes the failing tests are re-run > > > in a second process. The backend process reports to the > > > frontend process the set of failing tests so that they > > > can be memorized by the frontend process. > > > > OK, I knew about looponfailing....But as you say, looponfailing > watches > > for changes in all files. I thought there's an easier way to just > tell > > py.test to run previously failing tests. I guess it's a feature to > add > > to the list? > > Yes, it is. It requires some storage mechanism for py.test (and the > py lib > in general), for example a '.' directory in the home-directory of the > user. > But it should work for win32 as well, of course. I am not sure how > you can construct a user specific directory. Moreover, it should be > safe > against concurrent accesses e.g. from test sessions running at the > same > time. This is not super-hard but it requires some thought and > platform > knowledge. Once we have such a mechanism it becomes rather easy to > rerun previously failing tests. > Hi, Holger There are 2 environment variables in Windows that together give you a user-specific directory: HOMEDRIVE and HOMEPATH. So that should not be a problem. I think the harder part is the concurrent aspect. But I'm sure we can figure something out on Windows once we have a reference implementation on Unix. Grig

1 0