Skip to content
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

Ability to skip tests or allow errors due to SyntaxError #2817

Closed
anlutro opened this issue Oct 6, 2017 · 6 comments
Closed

Ability to skip tests or allow errors due to SyntaxError #2817

anlutro opened this issue Oct 6, 2017 · 6 comments
Labels
type: enhancement new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@anlutro
Copy link

anlutro commented Oct 6, 2017

I have a test that works with Python 3 type hints. I can easily deal with the typing module not existing in Python < 3.5 by using pytest.importorskip, however, in my test file I'm using type annotations like these:

def f(a: A): return a

This is not valid Syntax in Python 2.7, so the test run errors.

$ pytest
================================ test session starts ================================
platform linux2 -- Python 2.7.13, pytest-3.2.3, py-1.4.34, pluggy-0.4.0
rootdir: /home/andreas/code/allib.py, inifile:
plugins: pythonpath-0.7.1, cov-2.5.1
collected 21 items / 1 errors                                                        

====================================== ERRORS =======================================
_________________________ ERROR collecting tests/di_test.py _________________________
.venv/local/lib/python2.7/site-packages/_pytest/python.py:395: in _importtestmodule
    mod = self.fspath.pyimport(ensuresyspath=importmode)
.venv/local/lib/python2.7/site-packages/py/_path/local.py:662: in pyimport
    __import__(modname)
E     File "/home/andreas/code/allib.py/tests/di_test.py", line 7
E       def f(a: A): return a
E              ^
E   SyntaxError: invalid syntax
!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!
============================== 1 error in 0.22 seconds ==============================

As a temporary workaround, I will be moving my stubs with invalid Python 2 syntax to a separate module and deal with the SyntaxError myself, but it would be nice if I could just configure pytest to either skip importing the test at all or skip the error.

The SyntaxError already gets caught here, so it shouldn't be impossible to add some custom behaviour into the except clause.

@nicoddemus nicoddemus added type: enhancement new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature labels Oct 6, 2017
@nicoddemus
Copy link
Member

As a temporary workaround, I will be moving my stubs with invalid Python 2 syntax to a separate module

That's what I would suggest as an workaround.

@The-Compiler
Copy link
Member

I don't think there's a way for pytest to even import a module with the SyntaxError. The best thing it could do is offering an option to ignore files where a SyntaxError happened, but I'm not sure that's a good idea. You can already ignore them using a pytest_ignore_collect hook.

@RonnyPfannschmidt
Copy link
Member

i also already told on irc that the only way to handle this is to use a extra module and ignore_collect

within a module it is impossible to do at a sane cost
i'm inclined to close this one as the suggested variant is not implementable and the "clean" variant is based on ignore_collect to begin with

@nicoddemus
Copy link
Member

i'm inclined to close this one

I agree, the pytest_ignore_collect is a clean way of implementing this customization. @anlutro if you agree, we might add this use case as an example to the docs.

@anlutro
Copy link
Author

anlutro commented Oct 6, 2017

pytest_ignore_collect works for my use case.

@nicoddemus
Copy link
Member

@anlutro thanks for following up. I'm closing this, but if you would like to contribute an example to the docs it would be very welcome. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement new feature or API change, should be merged into features branch type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

4 participants