Mailman 3 April 2005 - pytest-dev

[py-dev] Re: [py-svn] r10665 - in py/branch/py-collect: . test test/terminal test/testing
by holger krekel April 16, 2005

April 16, 2005

Hi Jan, (reposted to py-dev), On Fri, Apr 15, 2005 at 15:15 +0200, Jan Balster wrote: > hpk(a)codespeak.net wrote: > i think you missed a return staement in terminal.py: > > + def main(self, args): > > + if self.config.option._remote: > > + from py.__impl__.test.terminal import remote > > + remote.main(self.config, self._file, self.config._origargs) > > + else: > > + super(TerminalSession, self).main(args) good catch, i didn't test --looponfailing so far which needs the return value. I actually want to add a test for looonfailing and will fix it then (it's good if tests fail first :-). btw, note that i didn't really get to do the clean implementation of "remote driving". It's still the old stdout/stderr redirection thingie, basically (but at least remote_exec() now directly allows to catch stdout/stderr per invocation, even if you have concurrent remote_exec() invocations :-). The thing is that i am pretty sure that execnet needs to support send/receive of (at least) simple objects. But maybe we should first try have a "pickle"-layer on top of channels because we want to assume anyway that the classes and the import structure are equivalent on the local and the remote side. With such an assumption we can probably send instances over the channel via pickle. cheers, holger

2 1

[py-dev] py.xml.html
by William McVey April 14, 2005

April 14, 2005

I've recently started using the py.xml.html package and ran across some additional HTML elements that would be nice to see get added to the defined __tagspec__ of the html class. Namely: "colgroup,col,map,area,blockquote,dl,dt,dd" "strong,script,style" Also, it would be nice if there were a flag that could turn off the XML short cut of <emptyelement />. In particular, when generating HTML for older browsers, it is much better to generate elements using the syntax of <emptyelement></emptyelement>. I've hacked this feature into xmlobj/visit.py in a very non-elegant fashion (always favoring the HTML-friendly approach, which works for me, but probably isn't appropriate for all cases). Let me know if other people think this is a good idea, and I can try to polish this up based off of an instantiation flag or something. -- William

2 2

[py-dev] new Channel callback
by Jan Balster April 14, 2005

April 14, 2005

Hi Holger, if I use the new channel.setcallback I still have to call gateway.exit() at the end. So I need a thread to wait for the remote side to finish. Is there a way to avoid this? Calling gateway.exit() form the callback would be fine for me, but I'm afraid that won't work. Jan

3 5

[py-dev] Greenlets fixed
by Armin Rigo April 13, 2005

April 13, 2005

Hi, 'py.magic.greenlet' wasn't working properly on MacOSX. This notice is to tell you that I found and fixed the problem. It wasn't specific to OSX, but to various details of the compiler and the architecture, so it showed up on OSX and by chance not on Linux/PC. If you had problems on other platforms (typically getting RuntimeError: maximum recursion depth exceeded), it would have been fixed too. Armin

1 0

[py-dev] Re: [py-svn] r10550 - py/dist/py/path/local
by Brian Dorsey April 12, 2005

April 12, 2005

Armin, This change breaks py.test on windows for me, since os.path.samefile doesn't seem to exist in windows. Take care, -Brian On Apr 12, 2005 7:24 AM, arigo(a)codespeak.net <arigo(a)codespeak.net> wrote: > Author: arigo > Date: Tue Apr 12 16:24:09 2005 > New Revision: 10550 > > Modified: > py/dist/py/path/local/local.py > Log: > Oups. Crashed if the co_filename stored in .pyc files doesn't exist at all. > > Modified: py/dist/py/path/local/local.py > ============================================================================== > --- py/dist/py/path/local/local.py (original) > +++ py/dist/py/path/local/local.py Tue Apr 12 16:24:09 2005 > @@ -347,8 +347,13 @@ > co = py.std.marshal.load(f) > path1 = co.co_filename > path2 = str(self) > - if path1 == path2 or os.path.samefile(path1, path2): > + if path1 == path2: > return co > + try: > + if os.path.samefile(path1, path2): > + return co > + except OSError: # probably path1 not found > + pass > finally: > f.close() > except py.error.Error: > _______________________________________________ > py-svn mailing list > py-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/py-svn >

2 3

[py-dev] Re: reponsiveness of tkinter frontend
by holger krekel April 10, 2005

April 10, 2005

Hi Jan, On Sun, Apr 10, 2005 at 13:56 +0200, Jan Balster wrote: > holger krekel wrote: > > On Sun, Apr 10, 2005 at 12:28 +0200, Jan Balster wrote: > >>The tree is updated for every call to guidriver.start and guidriver.end. > >>If you can see many tree items, it's very slow. That's a problem with > >>the tktree package I use. > > > > It's not possible for to just update part of the tree? > > > The tree widget can't change a simple node into a expandable node (node > with child nodes). > The tree uses a callback to build nodes on demand. If a collector > starts, the coressponding node has no childnodes. If the next test > starts, the node has to be changed into a expandable node. To do this > the parent node will be collapsed and expanded again. The callback will > build the 'collector'node as an expandable node, because it has childtests. I think i understand. It's unfortunate, then, that the Tktree widget can't efficiently handle growing trees. > >>I can write quickly a simple frontend with a list for failed and skipped > >>tests if you need a more responsive gui. That would be useful. If possible, i'd put this into a separate tab. Keeping a full tree view of all tests (with failing/passing/skipped just by color) seems worthwhile. But the "failing test list" with the checkboxes should be the default. Note that the search-query-interface, i mentioned, is not there yet. cheers, holger

2 2

[py-dev] Re: reponsiveness of tkinter frontend
by holger krekel April 10, 2005

April 10, 2005

Hi Jan, (CCed to py-dev because other might be interested yadda yadda) On Sun, Apr 10, 2005 at 12:28 +0200, Jan Balster wrote: > holger krekel wrote: > > Hi Jan, > > > > i was wondering if you know why tkinter does not > > remain responsive throughout the testing process. > > I have been using it a couple of times but felt > > that the UI often blocked. > > The tree is updated for every call to guidriver.start and guidriver.end. > If you can see many tree items, it's very slow. That's a problem with > the tktree package I use. It's not possible for to just update part of the tree? > I can write quickly a simple frontend with a list for failed and skipped > tests if you need a more responsive gui. I am not sure exactly here. But I think a simple list of failed tests with a fully responsive GUI (so i can inspect failures while testing continues seamlessly) would be a good idea. Btw, ExceptionFailures are subclasses of Failed and should be considered plain failures. The distinction only exists for reporting purposes (exception failures show differently than "normal" assertion failures or runtime Exceptions). So if i may wish for something: i would offer checkboxes for failed [x] skipped [ ] passed [ ] with only "failed" tests being shown by default. A status line (as well as the title of the windows, probably) shows the full test path being run at the moment. Note that i changed the default output for "py.test" to now show full module names. This became possible because the import system / logic got sanitized a lot and basically every test now always has a full package path, no matter if you run it directly or from some higher up directory. This uniformity is important for customization purposes. Also soon coming (i hope :-) is the feature i mention here: http://codespeak.net/py/current/doc/test.html#selecting-tests-by-queries-fu… The according tkinter interface could be a google style textfield where you can change the set of "selected tests" by dynamically specifying queries. The list of tests could even be updated after every key stroke ("incremental search"). I am just mentioning this because it might play a role in your tkinter internal design decisions. > > Another issue was, that when i clicked on a failure > > to investigate a problem that the ongoing testing > > process kept resetting the bottom window's focus > > to the first line. > > The tree widget remembers which item was selected before the tests are > executed and trys to reselect the item when it's recreated (test is > executed). So that shouldn't happen. I can't reproduce your result, can > you describe exactly what you did? Next time i have the problem, i try to describe it in more detail. thanks & cheers, holger

1 0

[py-dev] unitest.main() equivalent
by Huy April 9, 2005

April 9, 2005

Hi, I was wondering if there is a unittest.main() equivalent in py.test I'm basically trying to run my test directly in eclipse using pydev. Thanks, Huy

4 5

[py-dev] Does each test method get called with a new instance?
by Roy Smith April 8, 2005

April 8, 2005

Is the control flow example at http://codespeak.net/py/current/doc/test.html#example-for-managing- state-at-module-class-and-method-level correct? It implies that instance.test_42() and instance.test_23() both get called with the same instance. I would have thought a new instance would be created for each call. Hmmmm, a little experimenting shows that it is indeed correct. This seems counter-intuitive. I've always considered it a basic maxim of unit tests that each test ran in a pristine environment. What's the logic here?

7 19

Re: [py-dev] Error with py.test and scipy ...
by Jan Balster April 8, 2005

April 8, 2005

Pierre Barbier de Reuille wrote: > oops ... I may say I'm using the latest version of py.test (checked out > today), scipy 0.3.2 and python 2.3.5 on a linux debian plateform. > > Thanks ! > > Pierre Barbier de Reuille a écrit : > >> Hello, >> >> I just tried to use py.test. However, I experience segmentation fault >> when importing scipy module. Did anyone have the same problem before ? Yes. I used a fresh compiled Scipy 0.3.2 and Python 2.4 with latest py.test on SuSE 9.2 linux. Example: class TestClass: def test_scipy(self): import scipy assert 1==1 Report: =============================================================================== scipy_________test_pytest.py[1] segmentation fault It seems to be a problem in scipy_base. Here is what i did: in scipy_base/__init__.py comment out: from index_tricks import * from function_base import * from polynomial import * from scimath import * in common.py remove amin, amax, extract, insert, poly1d, r_ from the "from scipy_base import" statement in pilutil.py remove amin, amax, mgrid from the "from scipy_base import" statement Now the little testcase runs without a segfault. Hope this works for you. Jan

8 10