Skip to content

isfile check fails within pytest #2040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks done
satra opened this issue Nov 1, 2016 · 8 comments
Closed
3 tasks done

isfile check fails within pytest #2040

satra opened this issue Nov 1, 2016 · 8 comments
Labels
plugin: capture related to the capture builtin plugin type: bug problem that needs to be addressed

Comments

@satra
Copy link

satra commented Nov 1, 2016

the test below fails when running with pytest test.py but not with pytest -s test.py

  • pip list of the virtual environment you are using
$ pip list
pip (8.1.2)
py (1.4.31)
pytest (3.0.3)
setuptools (27.2.0)
wheel (0.29.0)
  • pytest and operating system versions

python 3.5.2
pytest 3.0.3
OS X (but i believe this fails on other OSes as well)

  • Minimal example if possible
import os

def test_isfile():
    assert os.path.isfile(True) == False
@nicoddemus
Copy link
Member

Oh wow, that's strange. Thanks for the report!

@nicoddemus nicoddemus added type: bug problem that needs to be addressed plugin: capture related to the capture builtin plugin labels Nov 2, 2016
@nicoddemus
Copy link
Member

nicoddemus commented Nov 2, 2016

It also passes with pytest test.py --capture=sys, so definitely has to do with file-descriptor capturing.

@nicoddemus
Copy link
Member

I think it's related to the fact that capfd is redirecting file descriptor 1 to a file, and 1 equals True. The same test fails if we pass 1 or 2 instead of True (equivalent to stdout and stderr), but not integers higher than that.

@The-Compiler
Copy link
Member

I don't think this is a bug. The same code (which simply tests if stdout is a file, in a rather obfuscated way) also fails without pytest involved when doing python foo.py > file.

@satra
Copy link
Author

satra commented Nov 2, 2016

@The-Compiler - you are correct in that python 3 treats 1 and True identically even though they have different datatypes. on python 2 this raises a TypeError.

would the recommendation for this test be to do: with capfd.disabled(): ? we will also look to see if we can modify the upstream code that this is testing.

@The-Compiler
Copy link
Member

bool is a subclass of int (isinstance(True, int) == True) both on Python 2 and Python 3. The reason this doesn't work on Python 2 is that os.path.isfile only accept paths (and not ints as file descriptors) there.

What's the point of this test, or how is the actual test looking like? At least with your minimal example, I think the test should just not exist at all 😉

@satra
Copy link
Author

satra commented Nov 2, 2016

essentially it's an embedded test of hashing a hierarchical dictionary. the key value pairs could have as value a file path. and the os.path.isfile(value) checks to see if it's a file and replaces the value with content hash of the file. since some of the values are True bools the test started failing with pytest, when it didn't fail with nose.

@nicoddemus
Copy link
Member

I would recommend using capfd.disabled() in this case if it solves this specific problem. IMO this is a very edge-case and not much can be done on our side to fix this. Feel free to reopen if you feel otherwise and this warrants more discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin: capture related to the capture builtin plugin type: bug problem that needs to be addressed
Projects
None yet
Development

No branches or pull requests

3 participants