From pinard at iro.umontreal.ca Mon Apr 17 16:22:00 2006 From: pinard at iro.umontreal.ca (=?iso-8859-1?Q?Fran=E7ois?= Pinard) Date: Mon Apr 17 16:23:10 2006 Subject: [py-dev] py.test in Unicode context Message-ID: <20060417142200.GA9148@phenix.sram.qc.ca> Hi, people. I hope this is an appropriate forum for discussing such things, otherwise, please friendly tell me! :-) For a while now, and more as it goes, we are using py.test and py.log in a some projects. A few being bigger, most being smaller... A few weeks ago, we started the experiment of fully converting a set of programs to full Unicode internally. That is, for example, *all* constant strings in the sources got a 'u' prepended by the application of ``unipy *.py``, where ``unipy`` is a script of ours. A bit sadly, Python is not fully ready for such usage -- comments censored :-) -- yet with a few appropriate local stunts, it seems we can manage nevertheless. In fact, it sounds promising. The ``unipy`` scripts adds the following special line near the start of Python modules:: from Unicode import file, isinstance, open, os, str, sys, unicode and also cleans out pre-existing import statements from ``os`` and ``sys`` references. The effect is that, for example, ``file`` or ``os.popen`` have a Unicode-aware filter automatically installed around the real file object, and this is true as well for ``sys.stdin`` and ``sys.stdout`` say, but only for modules using the special ``from`` line, the real things are left alone for non unipy-ized modules. py.test and py.log does not behave well in such contexts, and I would much like not giving on them, so my incentive for this conversation. I'll likely adjust a local copy of py.log, but py.test is less easy for me. It uses some magic by which, for example, ``sys.stdout`` is overriden in the tested module space, and by a ``cStringIO`` object. For one thing, ``cStringIO`` does not work with Unicode strings, while ``StringIO`` does, but it should not even be a problem, because the special ``sys`` imported from our ``Unicode`` module should, for example, write only 8-bit strings to the real ``sys.stdout``, so I would guess the interception installed by ``py.test`` is not low level enough: it should ideally not play in the tested module namespace. Do you have any opinion, suggestion, or thought you would feel like sharing, on this matter? [On a parallel line of thought, I also wonder if the pylib project could not adopt, as one of its sub-projects, the seek for a workable solution to the problematic of those like us, who try to match Python and Unicode for real. :-)] -- Fran?ois Pinard http://pinard.progiciels-bpi.ca From timothy.grant at gmail.com Fri Apr 21 11:14:06 2006 From: timothy.grant at gmail.com (Timothy Grant) Date: Fri Apr 21 11:14:45 2006 Subject: [py-dev] py.test munging strings in asserts? Message-ID: Hi everyone, I posted this to the python list, but was also asked to post it here, so I will do so. I'm playing around with py.test and writing a parser for it's output for use in TextMate. I've run into what appears to be a strange phenomenon, but which is likely me doing something wrong. I'm writing a test to test some HTML output and the test fails for several reasons, all of which I understand but one. Here's the output (I've surrounded the problem area with *** to make it a little more visible. ======================================================== def test_error_summary(): text = ''' PyTestMate

Error in /Users/tjg/code/textmate/test_pytestmate.py at line 17

   [/Users/tjg/code/textmate/test_pytestmate.py:17]
''' assert pytestmate.create_output( ['[/Users/tjg/code/textmate/test_pytestmate.py:17]'] E ) == text > assert '\n\n\nPyTestMate\n\n***<...mate/test_pytestmate.py*** at line 17
[/Users/tjg/code/textmate/test_pytestmate.py:17]
\n' == '\n\n\nPyTestMate\n\n***<...st_pytestmate.py*** at line 17

\n
\n[/Users/tjg/code/textmate/test_pytestmate.py:17]\n
\n\n' + where '\n\n\nPyTestMate\n\n<...mate/test_pytestmate.py at line 17
[/Users/tjg/code/textmate/test_pytestmate.py:17]
\n' = (['[/Users/tjg/code/textmate/test_pytestmate.py:17]']) + where = pytestmate.create_output [/Users/tjg/code/textmate/test_pytestmate.py:55] =============================================== granted the left side of that equality could be messed up due to create_output() NOT doing the right thing. But the right side is simply the contents of the variable "text" so WHY is the first part of the path being substituted with "..."? Any insight greatly appreciated. -- Stand Fast, tjg. From jan at balster.info Fri Apr 21 12:16:08 2006 From: jan at balster.info (Jan Balster) Date: Fri Apr 21 12:17:03 2006 Subject: [py-dev] py.test munging strings in asserts? In-Reply-To: References: Message-ID: <4448B0E8.5010307@balster.info> Hi Timothy! The output is truncated to 240 characters, which is exactly the length of your strings in the output. The dots are only indicators, that the output was truncated. See py/test/terminal/terminal.py:439 and py/code/save_repr.py for explanations. As stated in the comments, we probably need a command line switch to toggle the behavior. The test of equality is not affected by the truncation of the output! If you write the text to stdout or a file, you will see it in it's whole glory. example: def test_output(): long_string = '/' * 238 # 238 + two "'" for the string representation == 240 longer_string = 'start' + long_string + 'end' # will be truncated print longer_string assert long_string == longer_string If you have any further questions, don't hesitate to ask! Cheers, Jan > I'm writing a test to test some HTML output and the test fails for > several reasons, all of which I understand but one. > > Here's the output (I've surrounded the problem area with *** to make > it a little more visible. > > ======================================================== > def test_error_summary(): > text = ''' > > > PyTestMate > > > > > >

Error in href="txmt://open/?url=file:///Users/tjg/code/textmate/test_pytestmate.py&line=17">/Users/tjg/code/textmate/test_pytestmate.py > at line 17

> 
>    [/Users/tjg/code/textmate/test_pytestmate.py:17]
>
> > ''' > > assert pytestmate.create_output( > ['[/Users/tjg/code/textmate/test_pytestmate.py:17]'] > E ) == text >> assert '\n\n\nPyTestMate\n\n***<...mate/test_pytestmate.py*** at line 17
[/Users/tjg/code/textmate/test_pytestmate.py:17]
\n' == '\n\n\nPyTestMate\n\n***<...st_pytestmate.py*** at line 17

\n
\n[/Users/tjg/code/textmate/test_pytestmate.py:17]\n
\n\n' > + where '\n\n content="text/html; charset=utf-8" > />\nPyTestMate\n\n<...mate/test_pytestmate.py at > line 17
[/Users/tjg/code/textmate/test_pytestmate.py:17]
\n' > = 0x42e870>(['[/Users/tjg/code/textmate/test_pytestmate.py:17]']) > + where = > pytestmate.create_output > > [/Users/tjg/code/textmate/test_pytestmate.py:55] > =============================================== > > granted the left side of that equality could be messed up due to > create_output() NOT doing the right thing. But the right side is > simply the contents of the variable "text" so WHY is the first part of > the path being substituted with "..."? > > Any insight greatly appreciated. > > > -- > Stand Fast, > tjg. > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > From timothy.grant at gmail.com Sat Apr 22 07:33:52 2006 From: timothy.grant at gmail.com (Timothy Grant) Date: Sat Apr 22 07:34:32 2006 Subject: Fwd: [py-dev] py.test munging strings in asserts? In-Reply-To: References: <4448B0E8.5010307@balster.info> Message-ID: Meant to reply all and only replied to Jan. ---------- Forwarded message ---------- From: Timothy Grant Date: Apr 21, 2006 3:09 PM Subject: Re: [py-dev] py.test munging strings in asserts? To: Jan Balster While the test for equality my not be affected by the truncation of the output, the ability to effectively debug the FAILURE of the assertion is negatively impacted by this. When I have two long strings that are almost but not quite equal, how am I to go about debugging the test failure, when the discrepancy may be hidden by the "..." I could easily envision (having done this in the past with other tools) writing a command line utility that would look for an assertion that contained a long string comparison, and then diff the two strings to help point out where the problem is. I realize that py.test allows me to use "print" to my heart's content, but I that makes the output even MORE verbose. I'd love any suggestions. On 4/21/06, Jan Balster wrote: > Hi Timothy! > > The output is truncated to 240 characters, which is exactly the length of your > strings in the output. The dots are only indicators, that the output was truncated. > See py/test/terminal/terminal.py:439 and py/code/save_repr.py for explanations. > As stated in the comments, we probably need a command line switch to toggle the > behavior. > > The test of equality is not affected by the truncation of the output! If you > write the text to stdout or a file, you will see it in it's whole glory. > > example: > > def test_output(): > long_string = '/' * 238 # 238 + two "'" for the string representation == 240 > longer_string = 'start' + long_string + 'end' # will be truncated > > print longer_string > > assert long_string == longer_string > > If you have any further questions, don't hesitate to ask! > > Cheers, > Jan > > > > I'm writing a test to test some HTML output and the test fails for > > several reasons, all of which I understand but one. > > > > Here's the output (I've surrounded the problem area with *** to make > > it a little more visible. > > > > ======================================================== > > def test_error_summary(): > > text = ''' > > > > > > PyTestMate > > > > > > > > > > > >

Error in > href="txmt://open/?url=file:///Users/tjg/code/textmate/test_pytestmate.py&line=17">/Users/tjg/code/textmate/test_pytestmate.py > > at line 17

> > 
> >    [/Users/tjg/code/textmate/test_pytestmate.py:17]
> >
> > > > ''' > > > > assert pytestmate.create_output( > > ['[/Users/tjg/code/textmate/test_pytestmate.py:17]'] > > E ) == text > >> assert '\n\n\nPyTestMate\n\n***<...mate/test_pytestmate.py*** at line 17
[/Users/tjg/code/textmate/test_pytestmate.py:17]
\n' == '\n\n\nPyTestMate\n\n***<...st_pytestmate.py*** at line 17

\n
\n[/Users/tjg/code/textmate/test_pytestmate.py:17]\n
\n\n' > > + where '\n\n > content="text/html; charset=utf-8" > > />\nPyTestMate\n\n<...mate/test_pytestmate.py at > > line 17
[/Users/tjg/code/textmate/test_pytestmate.py:17]
\n' > > = > 0x42e870>(['[/Users/tjg/code/textmate/test_pytestmate.py:17]']) > > + where = > > pytestmate.create_output > > > > [/Users/tjg/code/textmate/test_pytestmate.py:55] > > =============================================== > > > > granted the left side of that equality could be messed up due to > > create_output() NOT doing the right thing. But the right side is > > simply the contents of the variable "text" so WHY is the first part of > > the path being substituted with "..."? > > > > Any insight greatly appreciated. > > > > > > -- > > Stand Fast, > > tjg. > > _______________________________________________ > > py-dev mailing list > > py-dev@codespeak.net > > http://codespeak.net/mailman/listinfo/py-dev > > > -- Stand Fast, tjg. -- Stand Fast, tjg. From hpk at trillke.net Sat Apr 22 15:17:01 2006 From: hpk at trillke.net (holger krekel) Date: Sat Apr 22 15:23:24 2006 Subject: [py-dev] py.test munging strings in asserts? In-Reply-To: <4448B0E8.5010307@balster.info> References: <4448B0E8.5010307@balster.info> Message-ID: <20060422131701.GD10825@solar.trillke> Hi Jan, hi Timothy, hi all, On Fri, Apr 21, 2006 at 12:16 +0200, Jan Balster wrote: > The output is truncated to 240 characters, which is exactly the length of your > strings in the output. The dots are only indicators, that the output was truncated. > See py/test/terminal/terminal.py:439 and py/code/save_repr.py for explanations. > As stated in the comments, we probably need a command line switch to toggle the > behavior. this was also discussed a bit on #pylib with carl ... i think we should rather not truncate the output by default unless we have a more exact method like showing diffs intelligently. The latter probably requires a bit of refactoring of exprinfo.py which contains the "intermediate values representation" logic. It currently produces plain "explanation" strings from traversing and evaluating the AST of the expression in question. It should probably produce more structured and more information-preserving information (maybe by producing string-like objects, Armin once produced a number of experiments for adding "color" meta information to strings seemlessly). If we knew the binary comparison operator in an assert expression then py.test could decide on methods how to show it. What do you think? best, holger From brian at dorseys.org Mon Apr 24 06:58:18 2006 From: brian at dorseys.org (Brian Dorsey) Date: Mon Apr 24 06:58:56 2006 Subject: [py-dev] py.test munging strings in asserts? In-Reply-To: <20060422131701.GD10825@solar.trillke> References: <4448B0E8.5010307@balster.info> <20060422131701.GD10825@solar.trillke> Message-ID: <66e877b70604232158r19b7766dlcdaad56765e94561@mail.gmail.com> On 22/04/06, holger krekel wrote: > this was also discussed a bit on #pylib with carl ... i think > we should rather not truncate the output by default unless > we have a more exact method like showing diffs intelligently. One small thing: I believe the reason it truncates now is because, sometimes applications compare strings that are so long that printing them out essentially locks up the terminal. So, I definately agree that showing intelligent diffs would be great, but even without that, I think some form of truncation should be the default. Perhaps with a switch to remove it - perhaps --no-magic already does that? Take care, -Brian From Bryan.Weingarten at watchguard.com Fri Apr 28 17:56:29 2006 From: Bryan.Weingarten at watchguard.com (Bryan Weingarten) Date: Fri Apr 28 17:58:50 2006 Subject: [py-dev] py.test Message-ID: <595c0ccd8fee4f82faf24d87bce04d9f3e9debc2@localhost> i talked to jan at pycon about putting snapshots of the py.test on the website in zip format and he seemed ok with it. the problem is that our firewall blocks subversion calls and i can't check out the code. subversion uses so many non-standard commands such as PROPFIND, etc. i had the sysadmin add the commands, but subversion wanted more holes poked in our firewall and we had already spend too much time with it and the security risk was too high to make so many changes to the firewall at once. so it would be very helpful if you could put weekly or monthly or maybe even just milestone dated snapshots on the site. thanks, bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20060428/3f8571e7/attachment.htm From jan at balster.info Fri Apr 28 18:10:03 2006 From: jan at balster.info (Jan Balster) Date: Fri Apr 28 18:10:42 2006 Subject: [py-dev] py.test In-Reply-To: <595c0ccd8fee4f82faf24d87bce04d9f3e9debc2@localhost> References: <595c0ccd8fee4f82faf24d87bce04d9f3e9debc2@localhost> Message-ID: <44523E5B.7010502@balster.info> Hi Bryan, please try http://python.org/pypi/py/0.8.0-alpha2 for now. A more official release is on the way, but you know, releases and dates ;) Cheers, Jan Bryan Weingarten wrote: > i talked to jan at pycon about putting snapshots of the py.test on the > website in zip format and he seemed ok with it. the problem is that > our firewall blocks subversion calls and i can't check out the code. > subversion uses so many non-standard commands such as PROPFIND, etc. i > had the sysadmin add the commands, but subversion wanted more holes > poked in our firewall and we had already spend too much time with it and > the security risk was too high to make so many changes to the firewall > at once. so it would be very helpful if you could put weekly or monthly > or maybe even just milestone dated snapshots on the site. > > thanks, > > bryan > > > > ------------------------------------------------------------------------ > > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From Bryan.Weingarten at watchguard.com Fri Apr 28 18:35:04 2006 From: Bryan.Weingarten at watchguard.com (Bryan Weingarten) Date: Fri Apr 28 18:36:54 2006 Subject: [py-dev] py.test Message-ID: <2a18240c1b1f31291f8ccdc7b1d29c6967648b09@localhost> thanks jan, Exactly what I wanted. Using py.test has been really great so far. bryan -----Original Message----- From: Jan Balster [mailto:jan@balster.info] Sent: Friday, April 28, 2006 9:10 AM To: Bryan Weingarten Cc: py-dev@codespeak.net Subject: Re: [py-dev] py.test Hi Bryan, please try http://python.org/pypi/py/0.8.0-alpha2 for now. A more official release is on the way, but you know, releases and dates ;) Cheers, Jan Bryan Weingarten wrote: > i talked to jan at pycon about putting snapshots of the py.test on the > website in zip format and he seemed ok with it. the problem is that > our firewall blocks subversion calls and i can't check out the code. > subversion uses so many non-standard commands such as PROPFIND, etc. > i had the sysadmin add the commands, but subversion wanted more holes > poked in our firewall and we had already spend too much time with it > and the security risk was too high to make so many changes to the > firewall at once. so it would be very helpful if you could put weekly > or monthly or maybe even just milestone dated snapshots on the site. > > thanks, > > bryan > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From geert at boskant.nl Sat May 6 00:10:35 2006 From: geert at boskant.nl (Geert Jansen) Date: Sat May 6 00:11:24 2006 Subject: [py-dev] win32 improvements Message-ID: <445BCD5B.7070403@boskant.nl> Hi, the attached patch improves win32 support for some of the command line utilities in the py library. - add support for CMD.EXE in env.py - add "env.cmd" that behaves like "eval `python env.py`" on Unix - add proper quoting for the various scripts in bin/win32 - end scripts in bin/win32 with newlines - set svn:eol-style native on bin/win32 scripts Regards, Geert -------------- next part -------------- A non-text attachment was scrubbed... Name: py-win32.patch Type: text/x-patch Size: 4361 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20060506/bbaf7959/py-win32-0001.bin From timothy.grant at gmail.com Sat May 6 05:30:13 2006 From: timothy.grant at gmail.com (Timothy Grant) Date: Sat May 6 05:30:52 2006 Subject: [py-dev] Ann: PyTestMate Message-ID: Hi everyone, I'm not sure there's anyone here who develops on Mac, nor if there is anyone who uses the wonderful TextMate editor on said Mac. However, if you do, and you're interested, I have created a little tool to help with py.test within TextMate. The link to my blog entry and the code itself is here... http://www.craigelachie.org/serendipity/index.php?/archives/41-PyTestMate.html -- Stand Fast, tjg. From jan at balster.info Sat May 6 10:53:28 2006 From: jan at balster.info (Jan Balster) Date: Sat May 6 10:54:23 2006 Subject: [py-dev] win32 improvements In-Reply-To: <445BCD5B.7070403@boskant.nl> References: <445BCD5B.7070403@boskant.nl> Message-ID: <445C6408.4000806@balster.info> Hi Geert, thanks for your patch. I committed it as revision 26847. cheers, Jan Geert Jansen wrote: > Hi, > > the attached patch improves win32 support for some of the command line > utilities in the py library. > > - add support for CMD.EXE in env.py > - add "env.cmd" that behaves like "eval `python env.py`" on Unix > - add proper quoting for the various scripts in bin/win32 > - end scripts in bin/win32 with newlines > - set svn:eol-style native on bin/win32 scripts > > Regards, > Geert > > > ------------------------------------------------------------------------ > > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From hpk at trillke.net Fri May 26 10:12:51 2006 From: hpk at trillke.net (holger krekel) Date: Fri, 26 May 2006 10:12:51 +0200 Subject: [py-dev] Little py.test patch In-Reply-To: <44760704.7000200@gmail.com> References: <44760704.7000200@gmail.com> Message-ID: <20060526081251.GU12245@solar.trillke> On Thu, May 25, 2006 at 21:35 +0200, Antonio Cuni wrote: > Hi Holger, > I've written a little patch for py.test that implements a new feature. thanks! > Basically, I noticed that often I do the following code-and-test cycle, > especially after a large refactoring: > - edit the code > - run all test with -x > - correct the bug (ofter a stupid one, like a type) > - restart the cycle did you notice the existing "--looponfailing" option? It aims to automize this cycle. i am a bit in a rush, sorry and best, holger > I don't like to run all tests without -x because often one small bug > affects many tests, so I don't want to wait for them to be completed. > > The problem with my approach is that when the failing tests are at the > end of the queue I have to wait long before all previous tests (that I > already know to pass) complete, so I wrote some code that let me to > start from a specific test (identified by a number) and skip the ones > that come before. > > The command-line option to do this is '-n'; when a test fails its number > is printed at the start of the traceback, just after the name, so we can > easily restart from there. > > I don't know how well written is the patch, because I know very little > of py.test internals, it may seem just a quick hack, but it does the job. > > Here is the diff against revision 26654, feel free to include in the > repository. > > ciao Anto > Index: defaultconftest.py > =================================================================== > --- defaultconftest.py (revision 26654) > +++ defaultconftest.py (working copy) > @@ -23,7 +23,10 @@ > help="disable catching of sys.stdout/stderr output."), > Option('-k', > action="store", dest="keyword", default='', > - help="only run test items matching the given (google-style) keyword expression"), > + help="only run test items matching the given (google-style) keyword expression"), > + Option('-n', > + action="store", dest="startfrom", default=0, > + help="only run test items whose count number is greater or equal to the given number"), > Option('-l', '--showlocals', > action="store_true", dest="showlocals", default=False, > help="show locals in tracebacks (disabled by default)"), > Index: session.py > =================================================================== > --- session.py (revision 26654) > +++ session.py (working copy) > @@ -7,7 +7,8 @@ > """ > def __init__(self, config): > self._memo = [] > - self.config = config > + self.config = config > + self.colitem_count = 0 > > def shouldclose(self): > return False > @@ -63,6 +64,9 @@ > if self.shouldclose(): > raise Exit, "received external close signal" > > + colitem.count = self.colitem_count > + self.colitem_count += 1 > + > outcome = None > colitem.startcapture() > try: > @@ -94,6 +98,7 @@ > return > if isinstance(colitem, py.test.Item): > self.skipbykeyword(colitem) > + self.skipbystartfrom(colitem) > res = colitem.run() > if res is None: > return py.test.Item.Passed() > @@ -124,6 +129,14 @@ > if not (eor ^ self._matchonekeyword(key, chain)): > py.test.skip("test not selected by keyword %r" %(keyword,)) > > + def skipbystartfrom(self, colitem): > + try: > + startfrom = int(self.config.option.startfrom) > + except ValueError: > + startfrom = 0 > + if colitem.count < startfrom: > + py.test.skip('test not selected by start from %d filter' % startfrom) > + > def _matchonekeyword(self, key, chain): > for subitem in chain: > if subitem.haskeyword(key): > Index: terminal/terminal.py > =================================================================== > --- terminal/terminal.py (revision 26654) > +++ terminal/terminal.py (working copy) > @@ -360,9 +360,9 @@ > # entry.frame.code.firstlineno != lineno: > # self.out.line("testcode: %s:%d" % (fn, lineno+1)) > if root == fn: > - self.out.sep("_", "entrypoint: %s" %(modpath)) > + self.out.sep("_", "entrypoint: %s (%d)" %(modpath, item.count)) > else: > - self.out.sep("_", "entrypoint: %s %s" %(root.basename, modpath)) > + self.out.sep("_", "entrypoint: %s %s (%d)" %(root.basename, modpath, item.count)) > > def getentrysource(self, entry): > try: -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From anto.cuni at gmail.com Fri May 26 11:36:03 2006 From: anto.cuni at gmail.com (Antonio Cuni) Date: Fri, 26 May 2006 11:36:03 +0200 Subject: [py-dev] Little py.test patch In-Reply-To: <20060526081251.GU12245@solar.trillke> References: <44760704.7000200@gmail.com> <20060526081251.GU12245@solar.trillke> Message-ID: <4476CC03.6060209@gmail.com> holger krekel wrote: > On Thu, May 25, 2006 at 21:35 +0200, Antonio Cuni wrote: >> Hi Holger, >> I've written a little patch for py.test that implements a new feature. > > thanks! > >> Basically, I noticed that often I do the following code-and-test cycle, >> especially after a large refactoring: >> - edit the code >> - run all test with -x >> - correct the bug (ofter a stupid one, like a type) >> - restart the cycle > > did you notice the existing "--looponfailing" option? > It aims to automize this cycle. Hi Holger, no, I didn't notice looponfailing, it's what I was searching for :-). ciao Anto From anto.cuni at gmail.com Thu May 25 21:35:32 2006 From: anto.cuni at gmail.com (Antonio Cuni) Date: Thu, 25 May 2006 21:35:32 +0200 Subject: [py-dev] Little py.test patch Message-ID: <44760704.7000200@gmail.com> Hi Holger, I've written a little patch for py.test that implements a new feature. Basically, I noticed that often I do the following code-and-test cycle, especially after a large refactoring: - edit the code - run all test with -x - correct the bug (ofter a stupid one, like a type) - restart the cycle I don't like to run all tests without -x because often one small bug affects many tests, so I don't want to wait for them to be completed. The problem with my approach is that when the failing tests are at the end of the queue I have to wait long before all previous tests (that I already know to pass) complete, so I wrote some code that let me to start from a specific test (identified by a number) and skip the ones that come before. The command-line option to do this is '-n'; when a test fails its number is printed at the start of the traceback, just after the name, so we can easily restart from there. I don't know how well written is the patch, because I know very little of py.test internals, it may seem just a quick hack, but it does the job. Here is the diff against revision 26654, feel free to include in the repository. ciao Anto -------------- next part -------------- A non-text attachment was scrubbed... Name: py.test.diff Type: text/x-patch Size: 3124 bytes Desc: not available Url : http://codespeak.net/pipermail/py-dev/attachments/20060525/3c2dcb16/attachment.bin From cfbolz at gmx.de Sun May 28 15:34:58 2006 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 28 May 2006 15:34:58 +0200 Subject: [py-dev] Little py.test patch In-Reply-To: <4476CC03.6060209@gmail.com> References: <44760704.7000200@gmail.com> <20060526081251.GU12245@solar.trillke> <4476CC03.6060209@gmail.com> Message-ID: <348899050605280634i5d373e54m63aacd6368a0e2ba@mail.gmail.com> 2006/5/26, Antonio Cuni : > > no, I didn't notice looponfailing, it's what I was searching for :-). Holger borrowed the time machine from guido :-) Cheers, Carl Friedrich From hpk at trillke.net Thu Jun 15 06:27:46 2006 From: hpk at trillke.net (holger krekel) Date: Thu, 15 Jun 2006 06:27:46 +0200 Subject: [py-dev] Minor typo In-Reply-To: <9A1F0FA9BF088D71A7565429@[192.168.1.100]> References: <9A1F0FA9BF088D71A7565429@[192.168.1.100]> Message-ID: <20060615042746.GT25313@solar.trillke> Hello Bruce, thanks for your nice feedback! The typo is fixed (and i think i often do this typo, btw :) best, holger On Sat, Jun 10, 2006 at 20:10 -0400, Bruce Webber wrote: > Holger, > > First, let me thank you for providing the excellent py.test tool and the > excellent documentation that goes along with it! I'm using py.test to unit > test an open source flashcard program I'm writing, and was referring to > your documentation at . > > I came across a minor typo in the table of contents and in the section > heading which reads: > > "2.2 how to write assertions about execptions" > > "execptions" should be spelled "exceptions". > > Regards, > > -- > Bruce Webber > brucewebber at fastmail.us > http://brucewebber.us > -- merlinux GmbH Steinbergstr. 42 31139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) From gry at ll.mit.edu Wed Jun 21 20:02:23 2006 From: gry at ll.mit.edu (George Young) Date: Wed, 21 Jun 2006 14:02:23 -0400 Subject: [py-dev] newbie crash, no attribute 'getimportname', rev 29094 Message-ID: <20060621140223.e29add46.gry@ll.mit.edu> [python 2.4.1, py "Checked out revision 29094"] {first time user of py.test} I just fetched revision 29094. I did [as root] python ./setup.py build python ./setup.py install All seemed well. Then cat >foo.py def test_h(): h = 0 assert h == 1 and py.test foo.py I get: Traceback (most recent call last): File "/usr/local/bin/py.test", line 4, in ? py.test.cmdline.main() File "/usr/local/lib/python2.4/site-packages/py/test/cmdline.py", line 17, in main failures = session.main(args) File "/usr/local/lib/python2.4/site-packages/py/test/terminal/terminal.py", line 34, in main return super(TerminalSession, self).main(args) File "/usr/local/lib/python2.4/site-packages/py/test/session.py", line 43, in main colitems = self._map2colitems(args) File "/usr/local/lib/python2.4/site-packages/py/test/session.py", line 142, in _map2colitems colitems.append(getfscollector(item)) File "/usr/local/lib/python2.4/site-packages/py/test/collect.py", line 49, in getfscollector current = current.join(name) File "/usr/local/lib/python2.4/site-packages/py/test/collect.py", line 250, in join x = super(Directory, self).join(name) File "/usr/local/lib/python2.4/site-packages/py/test/collect.py", line 206, in join self._prepare() File "/usr/local/lib/python2.4/site-packages/py/test/collect.py", line 186, in _prepare self._name2items = self.buildname2items() File "/usr/local/lib/python2.4/site-packages/py/test/collect.py", line 236, in buildname2items x = self.makeitem(p.basename, self.filefilter, self.recfilter) File "/usr/local/lib/python2.4/site-packages/py/test/collect.py", line 246, in makeitem Directory = py.test.Config.getvalue('Directory', p) File "/usr/local/lib/python2.4/site-packages/py/test/config.py", line 48, in getvalue mod = importconfig(p) File "/usr/local/lib/python2.4/site-packages/py/test/config.py", line 209, in importconfig return configpath.pyimport() File "/usr/local/lib/python2.4/site-packages/py/path/local/local.py", line 372, in pyimport modname = pkg.__package__.getimportname(self) AttributeError: 'Package' object has no attribute 'getimportname' What am I doing wrong? I tried explicitly putting the checkout directory in my PYTHONPATH; same result. I see that getimportname is defined in py/initpkg.py, but it's not clear to me when/how it's supposed to get run. -- George -- "Are the gods not just?" "Oh no, child. What would become of us if they were?" (C.S. Lewis) From hpk at trillke.net Thu Jun 22 09:35:22 2006 From: hpk at trillke.net (holger krekel) Date: Thu, 22 Jun 2006 09:35:22 +0200 Subject: [py-dev] newbie crash, no attribute 'getimportname', rev 29094 In-Reply-To: <20060621140223.e29add46.gry@ll.mit.edu> References: <20060621140223.e29add46.gry@ll.mit.edu> Message-ID: <20060622073522.GB5737@solar.trillke> Hi George, On Wed, Jun 21, 2006 at 14:02 -0400, George Young wrote: > [python 2.4.1, py "Checked out revision 29094"] > {first time user of py.test} > > I just fetched revision 29094. I did [as root] > python ./setup.py build > python ./setup.py install > All seemed well. > > Then cat >foo.py > def test_h(): > h = 0 > assert h == 1 > > and > py.test foo.py > > I get: > Traceback (most recent call last): I did a bit of investigation - is it so that your test_foo.py resides in a directory with many more files/directories in it? Does the problem persist if you put test_foo.py in a clean new directory? I think there is a somewhat intricate problem with the "auto detection" of test modules and directories which can result to your prescribed problem (i could reproduce it and putting test_foo.py in a separate directory resolved it - no real solution but hopefully it helps already enough for your case). best, holger From Raghu at syncsort.com Sun Jun 25 22:04:47 2006 From: Raghu at syncsort.com (Devarakonda, Raghuram) Date: Sun, 25 Jun 2006 16:04:47 -0400 Subject: [py-dev] py.test with jython Message-ID: Hi, Has anyone been able to make py.test work with jython? I will give it a try myself but I wanted to know if others already tried it. Thanks, Raghu. ps. Please cc to my email-id as I am not subscribed to the list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20060625/d8aad4fc/attachment.htm From cfbolz at gmx.de Sun Jun 25 23:01:24 2006 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Sun, 25 Jun 2006 23:01:24 +0200 Subject: [py-dev] py.test with jython In-Reply-To: References: Message-ID: <348899050606251401y3fc19c15s7d9b0e31d246823b@mail.gmail.com> Hi Raghu, 2006/6/25, Devarakonda, Raghuram : > Has anyone been able to make py.test work with jython? I will give it a try > myself but I wanted to know if others already tried it. I don't think anybody has tried and somehow I doubt that it works (at least until a new Jython version comes out), since py.test uses new style classes in lots of places. I guess the (hopefully coming soon :-) new version of Jython that has new style classes should be able to run it, since the py-lib is supposed to be python 2.2 compatible. Cheers, Carl Friedrich From Raghu at syncsort.com Mon Jun 26 02:36:34 2006 From: Raghu at syncsort.com (Devarakonda, Raghuram) Date: Sun, 25 Jun 2006 20:36:34 -0400 Subject: [py-dev] py.test with jython Message-ID: Hi Carl, Thanks for quick response. I am curious whether you are referring to Jython 2.1 while mentioning new style classes. I am going to use Jython-2.2a1 whose README does mention new-style classes as one of the changes. Thanks, Raghu. -----Original Message----- From: cfbolz at googlemail.com on behalf of Carl Friedrich Bolz Sent: Sun 6/25/2006 5:01 PM To: Devarakonda, Raghuram Cc: py-dev at codespeak.net Subject: Re: [py-dev] py.test with jython Hi Raghu, 2006/6/25, Devarakonda, Raghuram : > Has anyone been able to make py.test work with jython? I will give it a try > myself but I wanted to know if others already tried it. I don't think anybody has tried and somehow I doubt that it works (at least until a new Jython version comes out), since py.test uses new style classes in lots of places. I guess the (hopefully coming soon :-) new version of Jython that has new style classes should be able to run it, since the py-lib is supposed to be python 2.2 compatible. Cheers, Carl Friedrich -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/py-dev/attachments/20060625/0ea4c60d/attachment.htm From cfbolz at gmx.de Mon Jun 26 09:30:44 2006 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Mon, 26 Jun 2006 09:30:44 +0200 Subject: [py-dev] py.test with jython In-Reply-To: References: Message-ID: <348899050606260030i5dc4e9d9ga75c232e18f6f164@mail.gmail.com> Hi Raghu, 2006/6/26, Devarakonda, Raghuram : > I am curious whether you are referring to Jython 2.1 while mentioning new > style classes. I am going to use Jython-2.2a1 whose README does mention > new-style classes as one of the changes. Ah, cool, I didn't know that there was an alpha of the newest Jython, I was indeed referring to Jython 2.1. It would be great if you could report any problems with py.test on Jython 2.2 that you are having if you try it out. Cheers, Carl Friedrich From hpk at trillke.net Mon Jun 26 09:33:11 2006 From: hpk at trillke.net (holger krekel) Date: Mon, 26 Jun 2006 09:33:11 +0200 Subject: [py-dev] py.test with jython In-Reply-To: <348899050606260030i5dc4e9d9ga75c232e18f6f164@mail.gmail.com> References: <348899050606260030i5dc4e9d9ga75c232e18f6f164@mail.gmail.com> Message-ID: <20060626073311.GF5737@solar.trillke> Hi Raghu, On Mon, Jun 26, 2006 at 09:30 +0200, Carl Friedrich Bolz wrote: > 2006/6/26, Devarakonda, Raghuram : > > I am curious whether you are referring to Jython 2.1 while mentioning new > > style classes. I am going to use Jython-2.2a1 whose README does mention > > new-style classes as one of the changes. > > Ah, cool, I didn't know that there was an alpha of the newest Jython, > I was indeed referring to Jython 2.1. It would be great if you could > report any problems with py.test on Jython 2.2 that you are having if > you try it out. I guess that you probably have to say "--nomagic" as the "assert expression" reinterpretation presumes parser structures that likely are not present on Jython (but not 100% sure about it). best, holger From raghu at syncsort.com Mon Jun 26 17:37:49 2006 From: raghu at syncsort.com (Raghuram Devarakonda) Date: Mon, 26 Jun 2006 11:37:49 -0400 Subject: [py-dev] py.test with jython In-Reply-To: <348899050606260030i5dc4e9d9ga75c232e18f6f164@mail.gmail.com> References: <348899050606260030i5dc4e9d9ga75c232e18f6f164@mail.gmail.com> Message-ID: <449FFF4D.1010300@syncsort.com> Ok, I will give it a try and hopefully it works. Carl Friedrich Bolz wrote: > Hi Raghu, > > 2006/6/26, Devarakonda, Raghuram : >> I am curious whether you are referring to Jython 2.1 while mentioning >> new >> style classes. I am going to use Jython-2.2a1 whose README does mention >> new-style classes as one of the changes. > > Ah, cool, I didn't know that there was an alpha of the newest Jython, > I was indeed referring to Jython 2.1. It would be great if you could > report any problems with py.test on Jython 2.2 that you are having if > you try it out. > > Cheers, > > Carl Friedrich > From raghu at syncsort.com Tue Jun 27 15:13:40 2006 From: raghu at syncsort.com (Raghuram Devarakonda) Date: Tue, 27 Jun 2006 09:13:40 -0400 Subject: [py-dev] py.test with jython 22 Message-ID: <44A12F04.40903@syncsort.com> Hi, I am trying py.test with jython22 and I got the following error: marvin:pytest-test$ jython22 ~/pytest/py-dist/py/bin/py.test --nomagic inserting into sys.path: /home/raghu/pytest/py-dist Traceback (innermost last): File "/home/raghu/pytest/py-dist/py/bin/py.test", line 3, in ? File "/home/raghu/pytest/py-dist/py/bin/_findpy.py", line 34, in ? File "c:\Rags\pytest\py-dist\py\__init__.py", line 125, in ? File "c:\Rags\pytest\py-dist\py\initpkg.py", line 225, in initpkg File "c:\Rags\pytest\py-dist\py\initpkg.py", line 47, in __init__ TypeError: _new_impl(): expected 2 args; got 1 Any idea what might be wrong? Thanks, Raghu