How to use maybe_wrap_pytest_function_for_tracing method in Pytest

You don't provide a full example so maybe i am missing something. But here is an example of how it can work, using the request.cached_setup() helper:

def pytest_funcarg__res(request):
    def setup():
        print "res-setup"
    def teardown(val):
        print "res-teardown"
    return request.cached_setup(setup, teardown)

def test_hello(res):
    raise KeyboardInterrupt()

If you run this with "py.test" you get:

============================= test session starts ==============================
platform linux2 -- Python 2.7.3 -- pytest-2.2.5.dev4
plugins: xdist, bugzilla, pep8, cache
collected 1 items

tmp/test_keyboardinterrupt.py res-setup
res-teardown


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! KeyboardInterrupt !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
/home/hpk/p/pytest/tmp/test_keyboardinterrupt.py:10: KeyboardInterrupt

which shows that setup and teardown are called if a KeyboardInterrupt occurs during test execution.

PEP 336 - Make None Callable proposed a similar feature:

None should be a callable object that when called with any arguments has no side effect and returns None.

The reason for why it was rejected was simply "It is considered a feature that None raises an error when called."

These hooks work well for me:

def pytest_sessionstart(session):
    # setup_stuff

def pytest_sessionfinish(session, exitstatus):
    # teardown_stuff

But actually next fixture with session scope looks much prettier:

@fixture(autouse=True, scope='session')
def my_fixture():
    # setup_stuff
    yield
    # teardown_stuff

I was able to make your approach work, but there are few changes that are needed and mandatory.

1. The test should be run with a parent directory context
2. Both main folder and test folder should have a __init__.py
3. The imports in the tests should be a relative import and not a direct import

So below is my tree structure

root@5db7ad85dafd:/project# tree
.
 __init__.py
 a.py
 test
     __init__.py
     a.py

1 directory, 4 files

root@5db7ad85dafd:/project# python --version
Python 2.7.9

project/a.py

hello = 'tarun'

project/test/a.py

import unittest
from .. import a

class TestStringMethods(unittest.TestCase):
   def test_abc(self):
       assert a.hello == "tarun"

Notice the from .. import a which is import for this to work

Next we run the test being in the root folder of the project like below

root@5db7ad85dafd:/project# python -m unittest discover -t .. -s test -p "*.py"
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

-t here sets the top level import directory, so our relative imports can work -s tells which directory our tests are in -p tells what patter the test should be discovered in

When you want to run a individual test you will do something like below

python -m unittest discover -t .. -s test -p "a.py"

or

python -m unittest discover -t .. -s test -p "*.py" a

A picture is always worth more than words

Edit-1

Wanted to update my answer after seeing Peter's answer. The reason I didn't mention the import from a fixed named package was that it would mean that you need to know the name of the folder where the code is cloned and it is enforced to remain the same. But if you still want to go with that approach, then one approach is to move the actual into a sub-folder

So it would be repo/project/test/a.py and then in your tests you will use

from project import a

and then run it like below from the repo folder

root@5db7ad85dafd:/repo# python -m unittest discover -v -t project -s project.test -p "*.py"
test_abc (test.a.TestStringMethods) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

or like below from the test folder

root@5db7ad85dafd:/repo/project# python -m unittest discover -v -t .. -s test -p "*.py"
test_abc (project.test.a.TestStringMethods) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.001s

OK

In this case moving your project folder one level from root, will make sure that the project name is not dependent on the folder where your project is cloned

If the reason you're checking is so you can do something like if file_exists: open_it(), it's safer to use a try around the attempt to open it. Checking and then opening risks the file being deleted or moved or something between when you check and when you try to open it.

If you're not planning to open the file immediately, you can use os.path.isfile

Return True if path is an existing regular file. This follows symbolic links, so both islink() and isfile() can be true for the same path.

import os.path
os.path.isfile(fname) 

if you need to be sure it's a file.

Starting with Python 3.4, the pathlib module offers an object-oriented approach (backported to pathlib2 in Python 2.7):

from pathlib import Path

my_file = Path("/path/to/file")
if my_file.is_file():
    # file exists

To check a directory, do:

if my_file.is_dir():
    # directory exists

To check whether a Path object exists independently of whether is it a file or directory, use exists():

if my_file.exists():
    # path exists

You can also use resolve(strict=True) in a try block:

try:
    my_abs_path = my_file.resolve(strict=True)
except FileNotFoundError:
    # doesn't exist
else:
    # exists

See embedded comments in this modified version of your parser:

from pyparsing import *

selkwds = "atomname atomindex atomtype thiol".split()
func_name = MatchFirst(map(CaselessKeyword, selkwds))
NOT,AND,OR = map(CaselessKeyword,"NOT AND OR".split())
keyword = func_name | NOT | AND | OR

func_call = Forward()

integer = Word(nums).setParseAction(lambda t: int(t[0]))
alphaword = Word(alphas,alphanums)

# you have to be specific about what kind of things can be an arg,
# otherwise, an argless function call might process the next
# keyword or boolean operator as an argument;
# this kind of lookahead is commonly overlooked by those who
# assume that the parser will try to do some kind of right-to-left
# backtracking in order to implicitly find a token that could be
# mistaken for the current repetition type; pyparsing is purely
# left-to-right, and only does lookahead if you explicitly tell it to
# I assume that a func_call could be a function argument, otherwise
# there is no point in defining it as a Forward
func_arg = ~keyword + (integer | func_call | alphaword)

# add Groups to give structure to your parsed data - otherwise everything
# just runs together - now every function call parses as exactly two elements:
# the keyword and a list of arguments (which may be an empty list, but will
# still be a list)
func_call << Group(func_name + Group(Optional(delimitedList(func_arg) | '*')))

# don't name this func_call, its confusing with what you've 
# already defined above
func_call_expr = operatorPrecedence(func_call, [(NOT, 1, opAssoc.RIGHT),
                                           (AND, 2, opAssoc.LEFT),
                                           (OR , 2, opAssoc.LEFT)])

Let's test it out:

tests = """\
    atomname * and atomindex 1,2,3
    atomname xxx,yyy or atomtype rrr,sss
    thiol
    not atomindex 1,2,3
    not (atomindex 4,5,6) or atomname *""".splitlines()

for test in tests:
    print test.strip()
    print func_call_expr.parseString(test).asList()
    print

prints:

atomname * and atomindex 1,2,3
[[['atomname', ['*']], 'AND', ['atomindex', [1, 2, 3]]]]

atomname xxx,yyy or atomtype rrr,sss
[[['atomname', ['xxx', 'yyy']], 'OR', ['atomtype', ['rrr', 'sss']]]]

thiol
[['thiol', []]]

not atomindex 1,2,3
[['NOT', ['atomindex', [1, 2, 3]]]]

not (atomindex 4,5,6) or atomname *
[[['NOT', ['atomindex', [4, 5, 6]]], 'OR', ['atomname', ['*']]]]

The special variable __file__ contains the path to the current file. From that we can get the directory using either pathlib or the os.path module.

Python 3

For the directory of the script being run:

import pathlib
pathlib.Path(__file__).parent.resolve()

For the current working directory:

import pathlib
pathlib.Path().resolve()

Python 2 and 3

For the directory of the script being run:

import os
os.path.dirname(os.path.abspath(__file__))

If you mean the current working directory:

import os
os.path.abspath(os.getcwd())

Note that before and after file is two underscores, not just one.

Also note that if you are running interactively or have loaded code from something other than a file (eg: a database or online resource), __file__ may not be set since there is no notion of "current file". The above answer assumes the most common scenario of running a python script that is in a file.

References

1. pathlib in the python documentation.
2. os.path - Python 2.7, os.path - Python 3
3. os.getcwd - Python 2.7, os.getcwd - Python 3
4. what does the __file__ variable mean/do?

Looks like you haven't properly installed the header files and static libraries for python dev. Use your package manager to install them system-wide.

For apt (Ubuntu, Debian...):

sudo apt-get install python-dev   # for python2.x installs
sudo apt-get install python3-dev  # for python3.x installs

For yum (CentOS, RHEL...):

sudo yum install python-devel    # for python2.x installs
sudo yum install python3-devel   # for python3.x installs

For dnf (Fedora...):

sudo dnf install python2-devel  # for python2.x installs
sudo dnf install python3-devel  # for python3.x installs

For zypper (openSUSE...):

sudo zypper in python-devel   # for python2.x installs
sudo zypper in python3-devel  # for python3.x installs

For apk (Alpine...):

# This is a departure from the normal Alpine naming
# scheme, which uses py2- and py3- prefixes
sudo apk add python2-dev  # for python2.x installs
sudo apk add python3-dev  # for python3.x installs

For apt-cyg (Cygwin...):

apt-cyg install python-devel   # for python2.x installs
apt-cyg install python3-devel  # for python3.x installs

Note: python3-dev does not automatically cover all minor versions of python3, if you are using e.g. python 3.8 you may need to install python3.8-dev.

Yes, it was added in version 2.5. The expression syntax is:

a if condition else b

First condition is evaluated, then exactly one of either a or b is evaluated and returned based on the Boolean value of condition. If condition evaluates to True, then a is evaluated and returned but b is ignored, or else when b is evaluated and returned but a is ignored.

This allows short-circuiting because when condition is true only a is evaluated and b is not evaluated at all, but when condition is false only b is evaluated and a is not evaluated at all.

For example:

>>> 'true' if True else 'false'
'true'
>>> 'true' if False else 'false'
'false'

Note that conditionals are an expression, not a statement. This means you can't use statements such as pass, or assignments with = (or "augmented" assignments like +=), within a conditional expression:

>>> pass if False else pass
  File "<stdin>", line 1
    pass if False else pass
         ^
SyntaxError: invalid syntax

>>> # Python parses this as `x = (1 if False else y) = 2`
>>> # The `(1 if False else x)` part is actually valid, but
>>> # it can't be on the left-hand side of `=`.
>>> x = 1 if False else y = 2
  File "<stdin>", line 1
SyntaxError: cannot assign to conditional expression

>>> # If we parenthesize it instead...
>>> (x = 1) if False else (y = 2)
  File "<stdin>", line 1
    (x = 1) if False else (y = 2)
       ^
SyntaxError: invalid syntax

(In 3.8 and above, the := "walrus" operator allows simple assignment of values as an expression, which is then compatible with this syntax. But please don't write code like that; it will quickly become very difficult to understand.)

Similarly, because it is an expression, the else part is mandatory:

# Invalid syntax: we didn't specify what the value should be if the 
# condition isn't met. It doesn't matter if we can verify that
# ahead of time.
a if True

You can, however, use conditional expressions to assign a variable like so:

x = a if True else b

Or for example to return a value:

# Of course we should just use the standard library `max`;
# this is just for demonstration purposes.
def my_max(a, b):
    return a if a > b else b

Think of the conditional expression as switching between two values. We can use it when we are in a 'one value or another' situation, where we will do the same thing with the result, regardless of whether the condition is met. We use the expression to compute the value, and then do something with it. If you need to do something different depending on the condition, then use a normal if statement instead.

---

Keep in mind that it's frowned upon by some Pythonistas for several reasons:

• The order of the arguments is different from those of the classic condition ? a : b ternary operator from many other languages (such as C, C++, Go, Perl, Ruby, Java, JavaScript, etc.), which may lead to bugs when people unfamiliar with Python's "surprising" behaviour use it (they may reverse the argument order).
• Some find it "unwieldy", since it goes contrary to the normal flow of thought (thinking of the condition first and then the effects).
• Stylistic reasons. (Although the 'inline if' can be really useful, and make your script more concise, it really does complicate your code)

If you're having trouble remembering the order, then remember that when read aloud, you (almost) say what you mean. For example, x = 4 if b > 8 else 9 is read aloud as x will be 4 if b is greater than 8 otherwise 9.

Official documentation:

• Conditional expressions
• Is there an equivalent of C’s ”?:” ternary operator?