Hi folks,
yesterday, Harald asked me on #pylib regarding integration of
py.test with Scite and just now i replied to a similar
issue that Osmo posted on the issue tracker. See below.
I'd like to ask here as well: What would you like
for py.test's output in order for it to be most helpful
with your mode of testing and particularly integration
with editors?
You may also subscribe to
https://codespeak.net/issue/py-dev/issue57
if you want to follow the implementation of this feature.
cheers,
holger
P.S.: i am thinking of putting out a 0.9.2 with a few fixes.
If you have anything *now* is a good time to file.
--
collaborative expert contracting: http://merlinux.eu
PyPy Python/Compiler tool chain: http://codespeak.net/pypy
pylib py.test/greenlets/svn APIs: http://pylib.org
----- Forwarded message from holger krekel <[EMAIL PROTECTED]> -----
From: holger krekel <[EMAIL PROTECTED]>
To: Osmo Salomaa <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [issue57] Emacs and py.test tracebacks
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-Spambayes-Classification: ham; 0.00
Hi Osmo,
thanks for your report! If you have the following test_file.py:
def somefunc():
assert 0
def test_func():
somefunc()
you would probably like to get
/full/path/to/test_file1.py:3
in a line somewhere in the long traceback for this
failing test function, right?
What do you think about always adding a "summary" at
the end of a test run that looks like this?
/full/path/to/test_file1.py:3 AssertionError: 0
/full/path/to/test_file3.py:47 ValueError: 0 ...
...
Or, to ask more generally, what would be most helpful
output for your mode of testing with emacs?
holger
On Wed, Jul 23, 2008 at 04:35 +0000, Osmo Salomaa wrote:
> New submission from Osmo Salomaa <[EMAIL PROTECTED]>:
>
> Currently the filename and line numbers in py.test's long tracebacks are of
> form
> "[FILENAME:LINENO]". Emacs's compilation buffer does not understand that
> format.
> Changing it to form "FILENAME:LINENO:" (no brackets and a trailing colon)
> allows
> Emacs to parse that and render it as a clickable link. Emacs is able to parse
> the filenames and line numbers in the short tracebacks, but the links don't
> work
> because it would require the full filepath.
>
> I suspect other editors may suffer similarly, because there is no easy way to
> know that the opening bracket is not a part of the filename.
>
> Based on a quick look only a one line change to py/test/representation.py,
> method 'repr_failure_tblong' would be needed to fix the long tracebacks.
>
> ----------
> effort: easy
> messages: 147
> nosy: hpk, otsaloma
> priority: wish
> release: ???
> status: unread
> title: Emacs and py.test tracebacks
>
> _______________________________________________________
> py lib development tracker <[EMAIL PROTECTED]>
> <https://codespeak.net/issue/py-dev/issue57>
> _______________________________________________________
>
--
collaborative expert contracting: http://merlinux.eu
PyPy Python/Compiler tool chain: http://codespeak.net/pypy
pylib py.test/greenlets/svn APIs: http://pylib.org
----- End forwarded message -----
_______________________________________________
py-dev mailing list
py-dev@codespeak.net
http://codespeak.net/mailman/listinfo/py-dev
