@lesteve I cannot write it as:

@with_numpy
@parametrize(['to_hash', 'expected'],
             [(np.arange(100, dtype='<i8').reshape((10, 10))[:, :2],
               {'py2': '80f2387e7752abbda2658aafed49e086',
                'py3': '10a6afc379ca2708acfbaef0ab676eab'}), .... #others])
def method_name(to_hash, expected):
    # method body
    pass

I cannot use np in @parametrize args... They are still exposed.

Can you not use a function that returns the parameters i.e. something like:

def input_params():
    return [(np.arange(100, dtype='<i8').reshape((10, 10))[:, :2],
               {'py2': '80f2387e7752abbda2658aafed49e086',
                'py3': '10a6afc379ca2708acfbaef0ab676eab'}), .... #others]

@with_numpy
@parametrize(['to_hash', 'expected'], input_params())
def method_name:
    ...

Alternatively it seems like the pytest issue you pointed at was skipping parameters inside the input_params function (or at least that is what I wildly guessed from reading it).

Alternatively it seems like the pytest issue you pointed at was skipping parameters inside the input_params function (or at least that is what I wildly guessed from reading it).

I am reasonably confident the first option is not going to work but the latter one will. Here is a snippet that seems to work for me:

import pytest

try:
    import bla
except ImportError:
    bla = None


def params():
    skip = pytest.mark.skipif(bla is None, reason="bla not installed")
    return [skip('a'), skip('b')]


@pytest.mark.parametrize("param", params())
def test_foo(param):
    assert False

There may be better ways to do it though.

Well yes, the first one did not work, I tested it. It is because @parametrize runs at setup and the function call also happens at setup. But skipping does not happen. Which is why the second snippet you gave works, because pytest allows providing skipif as parameters to parametrize.

Here is a snippet that seems to work for me

Shall we go this way ? Giving out skipif markers ? Just because we have got one more alternative, out of the two I will vote the already done implementation because I am assuming it would look familiar to eyes of people familair with pytest (maybe ?)

Here is a link to standard example in documentation:

http://doc.pytest.org/en/latest/example/parametrize.html#apply-indirect-on-particular-arguments

As discussed I feel using parametrize in this case is too convoluted. So just use a dumb for loop.

Don't modify the imports order. If you have a plugin that orders imports alphabetically, disable it.

Nope you are not testing the same as the test as it was previously this should be:

is_hash_equal = (hash(obj1) == hash(obj2)) 
assert is_hash_equal == ob1 is obj2

Docstring not PEP0258.

But it seems like having a fixture with with_numpy is a good work-around.

You modified the test here too, keep it as it was:

for obj1, obj2 in itertools.product(obj_list, obj_list):
    is_hash_equal = hash(obj1) == hash(obj2)
    is_array_equal = np.all(obj1 == obj2)
    assert is_hash_equal == is_array_equal

Do not skip new lines, it seems a bit weird to me.

Great try but I think this makes the test quite hard to understand. I spent 10 minutes trying to put together something using pytest features but did not get anywhere.

I would be in favour of not using parametrize in this case and do something very close to what was originally here:

@with_numpy
def test_hashes_stay_the_same_with_numpy_objects:
    to_hash_list = ...
    expected_dict = ...
    for to_hash, expected in zip(to_hash_list, expected_list):
        assert hash(to_hash), expected

To be honest, my general feeling so far is that parametrize can make the test more obscure than it was. The only advantage compared to having a loop in the test is to create one test for each input argument, so I feel parametrize should be used sparingly.

But won't this for loop stop if the first test case itself is incorrect ?

That's fine. Running a separate test for each parameter is nice but not that crucial. If it makes the test hard to understand then we should give up on using parametrize.

Define a temporary variable to make this less obscure to read:

is_hash_equal = hash(a, coerce_mmap=coerce_mmap) == hash(m, coerce_mmap==coerce_mmap)
assert is_hash_equal == coerce_mmap

I think this second paranthesis is needed. Not having them failed tests for me. Because probably is_hash_equal == obj1 is obj2 will be true if all are not None.

Can you leave the expected_dict definition as it was. Remember: look at your diff and do not add changes if there is not a good reason for it.

I am experimenting ways to parametrize this in a good way so I kept this diff. Nevermind, I shifted this to a separate branch.

I would remove the docstring, I don't think it adds anything.

I would remove this comment the code is clear enough and it does not say much.

Remove this comment too.

Just a comment I found out while reading the doc that you can do:

input_list = [...]
@parametrize('obj1', input_list)
@parametrize('obj2', input_list)
def test_trivial_hash(obj1, obj2):
    ...

and this will have the same effect, i.e. iterating on the cartesian product of input_list with itself.

I thought of doing this, but then I stopped, thinking that for the first look I should not demonstrate my diff which introduces a not so special list in global scope.

But now we're on the same boat, so modifying it...

You need to remove [py_version_str] to get the tests to pass I believe.

Hmmm I missed that is that a new thing?

OK it's not I see it in the diff below, sorry.

Okay, cool 😄