Mailman 3 April 2006 - pytest-dev

RE: [py-dev] py.test
by Bryan Weingarten April 28, 2006

April 28, 2006

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(a)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(a)codespeak.net > http://codespeak.net/mailman/listinfo/py-dev

1 0

[py-dev] py.test
by Bryan Weingarten April 28, 2006

April 28, 2006

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

2 1

[py-dev] py.test munging strings in asserts?
by Timothy Grant April 24, 2006

April 24, 2006

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 = '''<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>PyTestMate</title> <style type="text/css"> .error {color : #FF0000} </style> </head> <body> <p>Error in <a href="txmt://open/?url=file:///Users/tjg/code/textmate/test_pytestmate.py&line=17">/Users/tjg/code/textmate/test_pytestmate.py</a> at line 17</p> <pre> [/Users/tjg/code/textmate/test_pytestmate.py:17] </pre> </body> </html>''' assert pytestmate.create_output( ['[/Users/tjg/code/textmate/test_pytestmate.py:17]'] E ) == text > assert '<html>\n<head>\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>PyTestMate</title>\n\n***<...mate/test_pytestmate.py***</a> at line 17<br/><pre>[/Users/tjg/code/textmate/test_pytestmate.py:17]</pre></body>\n</html>' == '<html>\n<head>\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>PyTestMate</title>\n\n***<...st_pytestmate.py***</a> at line 17</p>\n<pre>\n[/Users/tjg/code/textmate/test_pytestmate.py:17]\n</pre>\n</body>\n</html>' + where '<html>\n<head>\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>PyTestMate</title>\n\n<...mate/test_pytestmate.py</a> at line 17<br/><pre>[/Users/tjg/code/textmate/test_pytestmate.py:17]</pre></body>\n</html>' = <function create_output at 0x42e870>(['[/Users/tjg/code/textmate/test_pytestmate.py:17]']) + where <function create_output at 0x42e870> = 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.

4 3

Fwd: [py-dev] py.test munging strings in asserts?
by Timothy Grant April 22, 2006

April 22, 2006

Meant to reply all and only replied to Jan. ---------- Forwarded message ---------- From: Timothy Grant <timothy.grant(a)gmail.com> Date: Apr 21, 2006 3:09 PM Subject: Re: [py-dev] py.test munging strings in asserts? To: Jan Balster <jan(a)balster.info> 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 <jan(a)balster.info> 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 = '''<html> > > <head> > > <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> > > <title>PyTestMate</title> > > > > <style type="text/css"> > > .error {color : #FF0000} > > </style> > > > > </head> > > <body> > > <p>Error in <a > > href="txmt://open/?url=file:///Users/tjg/code/textmate/test_pytestmate.py&line=17">/Users/tjg/code/textmate/test_pytestmate.py</a> > > at line 17</p> > > <pre> > > [/Users/tjg/code/textmate/test_pytestmate.py:17] > > </pre> > > </body> > > </html>''' > > > > assert pytestmate.create_output( > > ['[/Users/tjg/code/textmate/test_pytestmate.py:17]'] > > E ) == text > >> assert '<html>\n<head>\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>PyTestMate</title>\n\n***<...mate/test_pytestmate.py***</a> at line 17<br/><pre>[/Users/tjg/code/textmate/test_pytestmate.py:17]</pre></body>\n</html>' == '<html>\n<head>\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />\n<title>PyTestMate</title>\n\n***<...st_pytestmate.py***</a> at line 17</p>\n<pre>\n[/Users/tjg/code/textmate/test_pytestmate.py:17]\n</pre>\n</body>\n</html>' > > + where '<html>\n<head>\n<meta http-equiv="Content-Type" > > content="text/html; charset=utf-8" > > />\n<title>PyTestMate</title>\n\n<...mate/test_pytestmate.py</a> at > > line 17<br/><pre>[/Users/tjg/code/textmate/test_pytestmate.py:17]</pre></body>\n</html>' > > = <function create_output at > > 0x42e870>(['[/Users/tjg/code/textmate/test_pytestmate.py:17]']) > > + where <function create_output at 0x42e870> = > > 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(a)codespeak.net > > http://codespeak.net/mailman/listinfo/py-dev > > > -- Stand Fast, tjg. -- Stand Fast, tjg.

1 0

[py-dev] py.test in Unicode context
by François Pinard April 17, 2006

April 17, 2006

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

1 0