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, 17 Apr 2006 10:22:00 -0400 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, 21 Apr 2006 02:14:06 -0700 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, 21 Apr 2006 12:16:08 +0200 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 at 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: Fri, 21 Apr 2006 22:33:52 -0700 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 at 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, 22 Apr 2006 15:17:01 +0200 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: Sun, 23 Apr 2006 21:58:18 -0700 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, 28 Apr 2006 08:56:29 -0700 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: From jan at balster.info Fri Apr 28 18:10:03 2006 From: jan at balster.info (Jan Balster) Date: Fri, 28 Apr 2006 18:10:03 +0200 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 at 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, 28 Apr 2006 09:35:04 -0700 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 at balster.info] Sent: Friday, April 28, 2006 9:10 AM To: Bryan Weingarten Cc: py-dev at 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 at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev