Yet another method based on file(1) behavior:

>>> textchars = bytearray({7,8,9,10,12,13,27} | set(range(0x20, 0x100)) - {0x7f})
>>> is_binary_string = lambda bytes: bool(bytes.translate(None, textchars))

Example:

>>> is_binary_string(open('/usr/bin/python', 'rb').read(1024))
True
>>> is_binary_string(open('/usr/bin/dh_python3', 'rb').read(1024))
False

If you do not declare my_fixture as a fixture, then the test will not be able to use it as a fixture:

import pytest

def my_fixture():
    data = {'x': 1, 'y': 2, 'z': 3}
    return data

def test_my_fixture(my_fixture):
    assert my_fixture['x'] == 1

This script leads to an error:

  def test_my_fixture(my_fixture):
E       fixture 'my_fixture' not found
>       available fixtures: cache, capfd, capsys, doctest_namespace, monkeypatch, pytestconfig, record_xml_property, recwarn, tmpdir, tmpdir_factory
>       use 'pytest --fixtures [testpath]' for help on them.

The purpose of the fixtures is to prepare something before the test(s). And to kill it afterward. And NOT to be part of the test (e.g. in logging, reporting, ways of exception handling, etc). It is kind of a pre-condition, created by something else, and just given to the test.

If you just declare it as a function, and use it as a function, it is a function, not a fixture. And its failures become the failures of the test, not the general framework run.

Consider this example:

import pytest

@pytest.fixture()
def my_fixture():
    data = {'x': 1, 'y': 2, 'z': 3}
    print('prepare')
    yield data
    print('destroy')

def test_my_fixture(my_fixture):
    print('test it')
    assert my_fixture['x'] == 1

Also in this example try uncommenting the raising lines, and see the difference. It will be ERROR vs FAILURE. It is critical for how the test results are interpreted and handled later (e.g., by the developers, QA engineers, or whoever analyses the test results).

import pytest

@pytest.fixture()
def my_fixture():
    print('prepare')
    # raise Exception('Oops')
    yield None
    print('destroy')

def test_my_fixture(my_fixture):
    # raise Exception('Booms!')
    print('test it')

In the fixture:

======================================= test session starts ========================================
collected 1 item                                                                                    

t.py E

============================================== ERRORS ==============================================
________________________________ ERROR at setup of test_my_fixture _________________________________

    @pytest.fixture()
    def my_fixture():
        data = {'x': 1, 'y': 2, 'z': 3}
        print('prepare')
>       raise Exception('Oops')
E       Exception: Oops

t.py:7: Exception
===================================== 1 error in 0.03 seconds ======================================

In the test or any function called from the test:

======================================= test session starts ========================================
collected 1 item                                                                                    

t.py F

============================================= FAILURES =============================================
_________________________________________ test_my_fixture __________________________________________

my_fixture = {'x': 1, 'y': 2, 'z': 3}

    def test_my_fixture(my_fixture):
>       raise Exception('Booms!')
E       Exception: Booms!

t.py:12: Exception
===================================== 1 failed in 0.03 seconds =====================================

Also note that the fixtures have scopes: session, module, function. It will be difficult to demonstrate in a short example, but in that case, the fixture will be prepared and destroyed only once (usually only once) for multiple tests within that scope. This is important for the heavy-weight fixtures, such as the database pre-population. Such fixtures usually reside in the conftest.py pseudo-plugin in the directory structure (NB: this is not a regular module to be imported! by design, at least).

While taking a second look based on @LaurentBristiel 's comments, I realized that I need two colons, PLUS the full path to the exception, so

[pytest]
filterwarnings =
    ignore::django.utils.deprecation.RemovedInDjango20Warning

Thanks to all!

well, for anyone looking around here the first problem is solved. How:

removed the sys.stdout highjack and replaced it with a thread write(deleted also write function that's not needed, same with console_output_to_ui and its call):

self.__process = subprocess.Popen(cmd, stdout=PIPE,  universal_newlines=True, shell=False)
t = Thread(target=self.thread_read)
t.start()


def thread_read(self):
    while self.__process.poll() is None:
        line = self.__process.stdout.readline()
        temp = line.lstrip()
        temp = temp.replace("\n", "")
        # don't print empty lines
        if len(temp) > 1:
            self.ui.textEdit.append(temp)

this way in the ui textEdit I hav a log that looks like this:

evaluate_condition(): '6'
evaluate_condition(): '7'
evaluate_condition(): '8'
evaluate_condition(): '9'

and it's updated line by line just as the cmd window output.

Now working on a solution for problem no.2

Short Answer

It's boilerplate code that protects users from accidentally invoking the script when they didn't intend to. Here are some common problems when the guard is omitted from a script:

• If you import the guardless script in another script (e.g. import my_script_without_a_name_eq_main_guard), then the latter script will trigger the former to run at import time and using the second script's command line arguments. This is almost always a mistake.

• If you have a custom class in the guardless script and save it to a pickle file, then unpickling it in another script will trigger an import of the guardless script, with the same problems outlined in the previous bullet.

Long Answer

To better understand why and how this matters, we need to take a step back to understand how Python initializes scripts and how this interacts with its module import mechanism.

Whenever the Python interpreter reads a source file, it does two things:

• it sets a few special variables like __name__, and then

• it executes all of the code found in the file.

Let's see how this works and how it relates to your question about the __name__ checks we always see in Python scripts.

Code Sample

Let's use a slightly different code sample to explore how imports and scripts work. Suppose the following is in a file called foo.py.

# Suppose this is foo.py.

print("before import")
import math

print("before function_a")
def function_a():
    print("Function A")

print("before function_b")
def function_b():
    print("Function B {}".format(math.sqrt(100)))

print("before __name__ guard")
if __name__ == '__main__':
    function_a()
    function_b()
print("after __name__ guard")

Special Variables

When the Python interpreter reads a source file, it first defines a few special variables. In this case, we care about the __name__ variable.

When Your Module Is the Main Program

If you are running your module (the source file) as the main program, e.g.

python foo.py

the interpreter will assign the hard-coded string "__main__" to the __name__ variable, i.e.

# It's as if the interpreter inserts this at the top
# of your module when run as the main program.
__name__ = "__main__" 

When Your Module Is Imported By Another

On the other hand, suppose some other module is the main program and it imports your module. This means there's a statement like this in the main program, or in some other module the main program imports:

# Suppose this is in some other main program.
import foo

The interpreter will search for your foo.py file (along with searching for a few other variants), and prior to executing that module, it will assign the name "foo" from the import statement to the __name__ variable, i.e.

# It's as if the interpreter inserts this at the top
# of your module when it's imported from another module.
__name__ = "foo"

Executing the Module's Code

After the special variables are set up, the interpreter executes all the code in the module, one statement at a time. You may want to open another window on the side with the code sample so you can follow along with this explanation.

Always

1. It prints the string "before import" (without quotes).

2. It loads the math module and assigns it to a variable called math. This is equivalent to replacing import math with the following (note that __import__ is a low-level function in Python that takes a string and triggers the actual import):

# Find and load a module given its string name, "math",
# then assign it to a local variable called math.
math = __import__("math")

3. It prints the string "before function_a".

4. It executes the def block, creating a function object, then assigning that function object to a variable called function_a.

5. It prints the string "before function_b".

6. It executes the second def block, creating another function object, then assigning it to a variable called function_b.

7. It prints the string "before __name__ guard".

Only When Your Module Is the Main Program

8. If your module is the main program, then it will see that __name__ was indeed set to "__main__" and it calls the two functions, printing the strings "Function A" and "Function B 10.0".

Only When Your Module Is Imported by Another

8. (instead) If your module is not the main program but was imported by another one, then __name__ will be "foo", not "__main__", and it'll skip the body of the if statement.

Always

9. It will print the string "after __name__ guard" in both situations.

Summary

In summary, here's what'd be printed in the two cases:

# What gets printed if foo is the main program
before import
before function_a
before function_b
before __name__ guard
Function A
Function B 10.0
after __name__ guard

# What gets printed if foo is imported as a regular module
before import
before function_a
before function_b
before __name__ guard
after __name__ guard

Why Does It Work This Way?

You might naturally wonder why anybody would want this. Well, sometimes you want to write a .py file that can be both used by other programs and/or modules as a module, and can also be run as the main program itself. Examples:

• Your module is a library, but you want to have a script mode where it runs some unit tests or a demo.

• Your module is only used as a main program, but it has some unit tests, and the testing framework works by importing .py files like your script and running special test functions. You don't want it to try running the script just because it's importing the module.

• Your module is mostly used as a main program, but it also provides a programmer-friendly API for advanced users.

Beyond those examples, it's elegant that running a script in Python is just setting up a few magic variables and importing the script. "Running" the script is a side effect of importing the script's module.

Food for Thought

• Question: Can I have multiple __name__ checking blocks? Answer: it's strange to do so, but the language won't stop you.

• Suppose the following is in foo2.py. What happens if you say python foo2.py on the command-line? Why?

# Suppose this is foo2.py.
import os, sys; sys.path.insert(0, os.path.dirname(__file__)) # needed for some interpreters

def function_a():
    print("a1")
    from foo2 import function_b
    print("a2")
    function_b()
    print("a3")

def function_b():
    print("b")

print("t1")
if __name__ == "__main__":
    print("m1")
    function_a()
    print("m2")
print("t2")
      

• Now, figure out what will happen if you remove the __name__ check in foo3.py:

# Suppose this is foo3.py.
import os, sys; sys.path.insert(0, os.path.dirname(__file__)) # needed for some interpreters

def function_a():
    print("a1")
    from foo3 import function_b
    print("a2")
    function_b()
    print("a3")

def function_b():
    print("b")

print("t1")
print("m1")
function_a()
print("m2")
print("t2")

• What will this do when used as a script? When imported as a module?

# Suppose this is in foo4.py
__name__ = "__main__"

def bar():
    print("bar")
    
print("before __name__ guard")
if __name__ == "__main__":
    bar()
print("after __name__ guard")

You can make it work this way:

conftest.py:

import pytest


def pytest_addoption(parser):
    parser.addoption("--input1", action="store", default="default input1")
    parser.addoption("--input2", action="store", default="default input2")



@pytest.fixture
def input1(request):
    return request.config.getoption("--input1")


@pytest.fixture
def input2(request):
    return request.config.getoption("--input2")

test.py:

import pytest

@pytest.mark.unit
def test_print_name(input1, input2):
    print ("Displaying input1: %s" % input1)
    print("Displaying input2: %s" % input2)

CLI:

>py.test -s test.py --input1 tt --input2 12
================================================= test session starts =================================================
platform win32 -- Python 3.7.0, pytest-4.1.1, py-1.7.0, pluggy-0.8.1
rootdir: pytest, inifile:
collected 1 item

test.py Displaying input1: tt
Displaying input2: 12
.

============================================== 1 passed in 0.04 seconds ===============================================

For pytest >= 7.0

The doc now explicitely mentions this case should be solved this way (without pytest):

with warnings.catch_warnings():
    warnings.simplefilter("error")
    ...

though this may not completely solve some cases (dynamic checks: see this post).

The solution suggested for pytest < 7.0, below, now raises a DeprecationWarning. Thanks to @Warren-Weckesser for signaling this in comment!

Possible solution for pytest < 7.0

Yet it was not planned to be used like this, it's possible to "record" any possible warning raised, and use this to add another assertion to ensure the number of raised warnings is 0:

def test_AttrStr_parse_warnings():
    """Check parse() raises proper warnings in proper cases."""
    with pytest.warns(None) as record:
        _AttrStr('').parse()
    assert len(record) == 0

To ensure it works: adding warnings.warn('any message') in the second assertion let the test fail.

comparing 2 dictionaries using recursion:

Edited for python 3 (works for python 2 as well):

d1= {'a':{'b':{'cs':10},'d':{'cs':20}}}
d2= {'a':{'b':{'cs':30} ,'d':{'cs':20}},'newa':{'q':{'cs':50}}}

def findDiff(d1, d2, path=""):
    for k in d1:
        if k in d2:
            if type(d1[k]) is dict:
                findDiff(d1[k],d2[k], "%s -> %s" % (path, k) if path else k)
            if d1[k] != d2[k]:
                result = [ "%s: " % path, " - %s : %s" % (k, d1[k]) , " + %s : %s" % (k, d2[k])]
                print("\n".join(result))
        else:
            print ("%s%s as key not in d2\n" % ("%s: " % path if path else "", k))

print("comparing d1 to d2:")
findDiff(d1,d2)
print("comparing d2 to d1:")
findDiff(d2,d1)

Python 2 old answer:

def findDiff(d1, d2, path=""):
    for k in d1:
        if (k not in d2):
            print (path, ":")
            print (k + " as key not in d2", "\n")
        else:
            if type(d1[k]) is dict:
                if path == "":
                    path = k
                else:
                    path = path + "->" + k
                findDiff(d1[k],d2[k], path)
            else:
                if d1[k] != d2[k]:
                    print (path, ":")
                    print (" - ", k," : ", d1[k])
                    print (" + ", k," : ", d2[k])

Output:

comparing d1 to d2:
a -> b: 
 - cs : 10
 + cs : 30
comparing d2 to d1:
a -> b: 
 - cs : 30
 + cs : 10

By default, py.test captures the result of standard out so that it can control how it prints it out. If it didn't do this, it would spew out a lot of text without the context of what test printed that text.

However, if a test fails, it will include a section in the resulting report that shows what was printed to standard out in that particular test.

For example,

def test_good():
    for i in range(1000):
        print(i)

def test_bad():
    print('this should fail!')
    assert False

Results in the following output:

>>> py.test tmp.py
============================= test session starts ==============================
platform darwin -- Python 2.7.6 -- py-1.4.20 -- pytest-2.5.2
plugins: cache, cov, pep8, xdist
collected 2 items

tmp.py .F

=================================== FAILURES ===================================
___________________________________ test_bad ___________________________________

    def test_bad():
        print('this should fail!')
>       assert False
E       assert False

tmp.py:7: AssertionError
------------------------------- Captured stdout --------------------------------
this should fail!
====================== 1 failed, 1 passed in 0.04 seconds ======================

Note the Captured stdout section.

If you would like to see print statements as they are executed, you can pass the -s flag to py.test. However, note that this can sometimes be difficult to parse.

>>> py.test tmp.py -s
============================= test session starts ==============================
platform darwin -- Python 2.7.6 -- py-1.4.20 -- pytest-2.5.2
plugins: cache, cov, pep8, xdist
collected 2 items

tmp.py 0
1
2
3
... and so on ...
997
998
999
.this should fail!
F

=================================== FAILURES ===================================
___________________________________ test_bad ___________________________________

    def test_bad():
        print('this should fail!')
>       assert False
E       assert False

tmp.py:7: AssertionError
====================== 1 failed, 1 passed in 0.02 seconds ======================