TypeError when print statement encountered about autonose HOT 24 CLOSED

it works fine for me. What python version & OS are you running?

can you run it with the --console flag to see if it's specific to the GTK code?

I just did the following (after installing the virtualenv python package). Could you please let me know if it works after trying this?
(virtualenv will create a "fresh" python install, eliminating interference from other packages)

mkdir /tmp/autonose_test
virtualenv --no-site-packages /tmp/autonose_test/
cd /tmp/autonose_test/
./bin/easy_install autonose
mkdir proj
cd proj
echo -e 'def test_print():\n\tprint "test"\n\tassert False\n' > test_print.py 
../bin/autonose --console

from autonose.

Haven't run the code yet, but that was with the --console flag; I haven't gotten GTK to work yet.

from autonose.

Sorry it took so long. I did what you suggested, and everything went fine, except the stdout was not captured and displayed.

from autonose.

Also, python 2.6.4 and ArchLinux

from autonose.

A fix:

capture.py - line 74:

def formatError(self, test, err):
    """Add captured output to error report.
    """
    test.capturedOutput = output = self.buffer
    #self._buf = None

comment out self._buf = None

Also - for good measure, change:

from StringIO import StringIO

to-

from cStringIO import StringIO

from autonose.

antlong:

thanks very much for tracking that down! I've added --nocapture to the nose options in the latest commit, does that fix the issue?

As for the capture.py plugin, do you have any plans to submit this to the nose developers? I can't really do much about it in autonose (except disable the plugin altogether)

from autonose.

yeah, it will fix it short term. i sent an email to ned of coverage. i will follow up when he replies accordingly.

from autonose.

Hi guys, I'd like to help, but I'm at a bit of a loss. How is coverage.py involved in this?

from autonose.

isnt the capture.py plugin coverage? maybe im just really confused. if its not yours, im sorry to bother you :)

from autonose.

Nope: the coverage plugin is called cover.py, and I didn't write that one either! :)

from autonose.

ok ned thank you :)

gfxmonk, i think the best approach would be to disable it, for now. I made a ticket on nose's tracker but im not sure how long it would take to get upstream.

from autonose.

So I finally actually experienced this problem for myself, and it does not appear to be the fault of the capture plugin (although for autonose it still does make sense to disable this plugin).

The problem is in the deletion of modules. In runner.py, there are two functions: save_init_modules and restore_init_modules. The first takes a snapshot of imported modules just before the tests run; the second reverts the set of loaded modules to that original set, using the code del(sys.modules[modname]).

This has the effect (in theory) of causing all modules imported by the files under test to be re-imported, ensuring the latest version is always run when nosetests kicks off.

It seems StringIO is special somehow, and I can't say how, but its module-level function _complain_ifclosed seems to get set to None in this process. For now, I've added an import in save_init_modules so that it will not get removed. This isn't ideal, but I certainly can't think of a better idea...

I'm going to call this issue closed, but please let me know if you still experience this problem in the latest version (0.1.4) and I'll reopen it.

from autonose.

(closing)

from autonose.

cstringIO is a faster version of stringIO. it does have a few smaller differences, such as the module is not able to accept Unicode strings that cannot be encoded as plain ASCII strings, and it will create a read only object while stringIO creates a r+w object.

In this case, im not sure that we would write anyway, so cstringIO is the better choice for the performance boost.

from autonose.

erm, not quite sure what you're getting at. I don't actually use StringIO in autonose, but the capture plugins do (so it's not my choice, nor is it always correct to assume that cstringIO is present).

If cstringIO has the same problem we can add that to the list of modules to never delete, but I don't think that's necessary.

from autonose.

Hi,

I'm running version 0.2.2 and I cannot get the stdout. Has this been solved?

from autonose.

Can you paste a stack trace or something? Or do you get the same results as the original reporter? I thought this was fixed, but perhaps not...

from autonose.

What I do not see is the stdout from running nosetest test.py when one test fails. I do not get any error, the problem is that there is nothing reported in the autonose console. Do I send you an output file from autonose --debug?

from autonose.

Yeah, that ought to do :)

from autonose.

@gfxmonk Here you have the output from a failed test: http://paste.ubuntu.com/942110/

from autonose.

Hmm, Is that the whole thing? There's only one stacktrace line right
at the end, and it doesn't tell me much I'm afraid :/

from autonose.

This is a new one http://paste.ubuntu.com/943730/ with the traceback.print_stack() after forcing a test to fail.

from autonose.

Thanks for the full log, I'm thinking that's a different bug - I've experienced it myself, but not been able to figure out what it could be (admittedly I've not looked too hard, as I don't use autonose much myself). I've opened issue #24 to track this.

from autonose.

You are welcome :)

from autonose.