test_response_iter_lines_reentrant failing with python 2.7 and urllib 1.12

FAIL: test_response_iter_lines_reentrant (**main**.RequestsTestCase)
## Response.iter_lines() is not reentrant safe

Traceback (most recent call last):
  File "test_requests.py", line 1127, in test_response_iter_lines_reentrant
    assert len(list(r.iter_lines())) == 3
AssertionError

---

Ran 150 tests in 43.451s


@frispete That test is supposed to fail: it is marked `pytest.xfail`. You need to run the tests using py.test.


Hmm, PyPI hosts a py.test version 0.0, stating to use pytest for installation, and that is what I use: pytest 2.8.2. Otherwise the test suite wouldn't run at all.


@frispete How did you run the test? Because I clearly see it marked as `xfail`.


@Lukasa I build distribution packages for openSUSE. Since the tests will fail in Build Service due to "no network" policy during build, I test these packages in a local installation at least. 

cd requests-2.8.1
./test_requests.py

BTW, I considered to add a feature request to have an --local test option, e.g. using vcrpy.


@frispete We have a plan to swap to using pytest-httpbin, we just haven't done that yet.


@Lukasa Does that allow offline tests? Scratch that, I read the purpose: sounds great.


@frispete we have a similar policy in Debian and I follow the same workflow, testing requests locally.

I'm testing calling py.test (and py.test-3: on Debian we had to version the name, I know it's ugly...) directly and all the tests are fine (with one xfailed):

```
% py.test test_requests.py
% py.test-3 test_requests.py
```

@Lukasa it's a very good news the plan about switching to pytest-httpbin! I would like to help, is there a ticket about this?


@eriol Yup, see #2184. We're very close now, just got problems with one threaded test.  


@Lukasa Confirming this issue too (requests 2.8.1). The invocation method is setup.py test, which runs py.test directly. I was a bit confused too when I saw the mark.xfail, but it's definitely making the tests fail:

```
Ensures that we properly deal with different kinds of IO streams. ... ok

======================================================================
FAIL: test_response_iter_lines_reentrant (test_requests.RequestsTestCase)
Response.iter_lines() is not reentrant safe
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/koobs/repos/freebsd/ports/www/py-requests/work/requests-2.8.1/test_requests.py", line 1127, in test_response_iter_lines_reentrant
    assert len(list(r.iter_lines())) == 3
AssertionError

----------------------------------------------------------------------
Ran 150 tests in 94.706s

FAILED (failures=1)
*** Error code 1
```

pytest version is 2.7.1.


@koobs out of interest, what happens if you use a newer py.test?


@Lukasa It's on my list of ports to update, will report back post-update :)


@Lukasa Same failure with pytest 2.8.2 (latest py as well)

Edit: Fails with setuptools test command. Direct py.test passes (that test), but fails on another :)

```
TestTimeout.test_total_timeout_connect
<snip>
requests/adapters.py:423: ConnectionError
<snip>
1 failed, 164 passed, 1 xfailed in 87.75 seconds
```


@koobs So this suggests there's some problem with the py.test to `setup.py test` integration (given that xfail doesn't work appropriately).


@Lukasa I would concur given the tests/evidence so far. Perhaps @hpk42 could shed some light on it


I found this, which may be related: https://github.com/pytest-dev/pytest/issues/750


Glimpsing through the various comments here i am not sure what the precise question related to requests/pytest interactions, sorry.  Could you shed some light on this? :)


@hpk42 Thanks for responding :) TLDR is: tests marked xfail seem to be reported as failures (not expected failures, resulting in a OK on the test suite) for `setup.py test` and `python -m pytest` invocations of py.test (py.test direct works fine)


@koobs i can't reproduce. Both "python -m pytest" and "setup.py test" work fine for me for an xfailing test when using the standard integration https://pytest.org/latest/goodpractises.html#integration-with-setuptools-test-commands  (using pytest-2.8.2 but i think it worked before). 


@hpk42 Interesting. I'm out of ideas for isolating/debugging it from here, any thoughts? Just for clarity I was just +1 on the original report by @frispete