"try:", "except:" and "break:" lines always reported as missing under Jython

[nedbat]

Originally reported by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

---

This is using the suggested method of collecting coverage info under Jython and then building the report under CPython.

The problem is that Jython's sys.settrace does not do anything for the listed lines, whereas CPython thinks they could have been covered, so they are always reported as missing.

No response when asking about this on the Jython list. A workaround in coverage.py would be nice, might get round to writing one.

---

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/120
• This issue had attachments: issue120. See the original issue for details.

[nedbat]

Original comment by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

---

Just looked at this again. I have a patch for 3.7, which essentially treats these lines the same way docstrings are currently treated if "jython compatibility" is enabled.

Problem is, how do we detect when we should add jython compatibility? (we are running under CPython when we build the report) I've done it using a file naming convention in my code, but we'd obviously need a generic mechanism. Do we need to add an rc file configuration section for this, or is there a better way?

Incidentally, this has been reported as a Jython bug for some time, it's here

http://bugs.jython.org/issue1751

[nedbat]

A configuration option wouldn't be terrible: the author of the code knows that it's Jython, and isn't like to change from CPython to Jython or back very often. Also, not likely to have a mixture of the two.

You might have a problem with a library being tested on CPython and Jython, but then the try/except lines would be covered by the CPython test runs (I guess?)

Another option is to note that it was Jython at execution time, which we know because of the $py.class extension.

[nedbat]

Original comment by Geoff Bache (Bitbucket: geoffbache, GitHub: Unknown)

---

Attaching a patch for this issue against current tip. (though I have tested this against 3.7 but only applied it against tip)

In the end I have detected Jython compatibility by looking for a suitable $py.class file and a lack of .pyc file in the same directory. This is not foolproof but should be good enough for most purposes, and should be fairly easy to make it more sophisticated in future if desired.

(patch is the output of "hg bundle")

[nedbat]

Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary)

---

Unless I'm mistaken, at this point in time the coverage.py master will not run on either jython 2.5.3 which is the latest version packaged on Ubuntu, because with is not implemented. And jython 2.7 also fails because it uses the two argument form of enumerate which is not supported by jython. I'm under the impression that coverage.py can't run on jython unless a significant porting effort is done. Or jython improves python compatibility.

[nedbat]

I haven't tested on Jython in a long while, but I'm surprised you say that two-arg enumerate isn't supported. It looks like it is on Jython 2.7.0.

[nedbat]

Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary)

---

The stack trace of another jython issue shows:

#!python


  File "C:\cygwin64\home\cbannan\coveragepy\coverage\parser.py", line 99, in lines_matching
    for i, ltext in enumerate(self.lines, start=1):
TypeError: enumerate() takes at most 1 arguments (2 given)

which led me to believe enumerate only has 1 argument in Jython 2.7b2.

[nedbat]

Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary)

---

My bad, jython 2.7.0 indeed implements enumerate with two args. Sorry for the noise.

[nedbat]

Original comment by Loic Dachary (Bitbucket: dachary, GitHub: dachary)

---

With the current coverage.py master I get

#!bash

(v) loic@fold:~/software/coveragepy/issue-120/reproducer$ jython -m coverage run a.py
/home/loic/jython2.7.0/bin/jython: No module named multiprocessing; 'coverage' is a package and cannot be directly executed
(v) loic@fold:~/software/coveragepy/issue-120/reproducer$ jython --version
Jython 2.7.0

And the documentation suggests there is a compatible module which is named differently ? I tried to install multiprocessing but it fails with

#!bash

(v) loic@fold:~/software/coveragepy/issue-120/reproducer$ type pip
pip is /home/loic/jython2.7.0//bin/pip
(v) loic@fold:~/software/coveragepy/issue-120/reproducer$ pip install multiprocessing
...
running build_ext

building 'multiprocessing._multiprocessing' extension

error: Compiling extensions is not supported on Jython

----------------------------------------
Cleaning up...
Command "/home/loic/jython2.7.0/bin/jython -c "import setuptools, tokenize;__file__='/tmp/pip_build_loic/multiprocessing/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-4PbKrc-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip_build_loic/multiprocessing
Storing debug log for failure in /home/loic/.pip/pip.log

Also the jython documentation about coverage seems to suggest using python for coverage instead of jython ?

[nedbat]

This is still an issue:

$ cat bug120.py
def do():
   x = [ 1 ]
   for i in range(2):
       try:
           x[i]
       except IndexError:
           break
do()
$ .tox/jython/bin/jython -m coverage run bug120.py      # measure with Jython
$ .tox/py27/bin/coverage report -m                                # report with CPython
Name        Stmts   Miss  Cover   Missing
-----------------------------------------
bug120.py       8      3    63%   4, 6-7

[nedbat]

@geoffbache thanks for the patch, and sorry it's taken me so long to look at it. I would detect Jython I think by recording the Python implementation in the data file. But this raises tricky questions about multiple implementations being combined together.

I wonder about solving this with a .coveragerc that explicitly excludes the missing lines instead?