Coverage.py on Jython

124 views
Skip to first unread message

Geoff Bache

unread,
Dec 10, 2010, 4:51:06 PM12/10/10
to Coverage.py Development
Hi all,

I'd like to respond to Ned's blog post about Jython from earlier this
year

http://nedbatchelder.com/blog/201005/coveragepy_on_jython.html

I'm now working on a Jython project and am very interested in making
it work with coverage.py. Would appreciate any advice and help that is
going.

I've noticed 3 things so far:
1) It doesn't handle Jython compiled files, which end in $py.class
rather than .pyc. That's now issue 100, and I've just attached a
patch, it's a fairly easy change.
2) "try:", "except:" and "break" lines never get shown as covered,
whatever happens.
3) It doesn't seem to work in callbacks from Java code. I have Jython
code which calls into Java and then back into Jython, and the latter
Jython code doesn't get marked.

Any suggestions or ideas welcome. You can also look at my nightly
report on this codebase, updated each night.

http://www.texttest.org/nightjob/coverage_pyusecase/index.html

The Jython files are the ones beginning with "java". At least point
(2) should be pretty obvious from these.

Regards,
Geoff Bache

Ned Batchelder

unread,
Dec 11, 2010, 8:28:05 AM12/11/10
to coverag...@googlegroups.com, Geoff Bache
As usual Geoff, you are on the cutting edge of Python coverage
measurement! :)

Can you give a few more details? What versions of Jython and Python,
and what OS are you using?

--Ned.

Geoff Bache

unread,
Dec 11, 2010, 2:56:00 PM12/11/10
to Coverage.py Development
Hi Ned,

I'm trying to write portable code (at least Linux + Windows), though
focussing mainly on Linux currently

I'm using Python 2.6 and Jython 2.5.1.

Not sure how much cutting edge I can claim though, as you can see I
haven't even enabled branch coverage yet :) It depresses me because
the numbers get lower...

By the way I think I worked out the cause of point 3 in the previous
post. It's because my callback occurs in a different thread that is
created by Java, and hence presumably isn't susceptible to
threading.settrace in Jython. Now I just need to find a thread-
specific way to enable coverage when the callback is made. Is there a
way already or do I need to add something?

I guess point 2 may also be a limitation of Jython rather than
coverage.py. I'll try to create a simple example and maybe ask on the
Jython list.

Regards,
Geoff

Geoff Bache

unread,
Feb 21, 2011, 10:27:29 AM2/21/11
to coverag...@googlegroups.com

As a follow up, I created issue 120 for point (2) after getting no reply on the Jython list. The rest of the issues I have worked around, though I had to hack a fair bit in coverage.py.

Regards,
Geoff

Ned Batchelder

unread,
Feb 21, 2011, 12:02:06 PM2/21/11
to coverag...@googlegroups.com, Geoff Bache
What sort of hacking in coverage.py have you been doing? I'd like it to
support Jython as much as it can.

--Ned.

Geoff Bache

unread,
Feb 21, 2011, 1:39:50 PM2/21/11
to coverag...@googlegroups.com, Ned Batchelder
Hi Ned,

Some of it is attached as a patch to issue 100, so it recognises the
source files at all. Obviously not much will work without this.

Another issue is the fact that Jython isn't always in control. At
least with Eclipse RCP, where I've been using it, control returns to
Java and stays there. This means that coverage.py doesn't collect
anything, because it relies on "atexit", and control never returns for
that to be called. To work around this I created a method
"process_shutdown" to basically call the save() method so that some
info came out at all.

Another one is that threads might be created by Java, and hence the
Jython code in them doesn't get tracked because threading.settrace
doesn't affect them. I added a little call that could be made when a
Java thread enters Jython code the first time.

The fourth is the issue I reported in issue 120, which I don't have a
solution for. It occurs to me that actually all that might be needed
is a way to exclude clause lines without excluding the whole clause. I
can't tell it to ignore "try." because then it will ignore every try
clause as well.

Regards,
Geoff

Reply all
Reply to author
Forward
0 new messages