parametrized: ids: support generator/iterator

[blueyed]

Fixes #759

Via blueyed#105.

[blueyed]

Fails on py35 only due to random order (easy to fix / ignore, but IIRC there was an issue for that already maybe?):

E       Failed: nomatch: 'test_parametrize_iterator.py::test1[param0] PASSED'
E           and: '============================= test session starts =============================='
E           and: 'platform linux -- Python 3.5.6, pytest-5.2.3.dev233+gc8053b8d1, py-1.8.0, pluggy-0.13.0 -- /home/travis/build/pytest-dev/pytest/.tox/py35-xdist/bin/python'
E           and: 'cachedir: .pytest_cache'
E           and: "hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/home/travis/build/pytest-dev/pytest/.hypothesis/examples')"
E           and: 'rootdir: /tmp/pytest-of-travis/pytest-0/popen-gw0/test_parametrize_iterator0'
E           and: 'plugins: hypothesis-4.44.2, forked-1.1.3, xdist-1.30.0'
E           and: 'collecting ... collected 6 items'
E           and: ''
E           and: 'test_parametrize_iterator.py::test1[param2] PASSED'
E           and: 'test_parametrize_iterator.py::test1[param3] PASSED'
E           and: 'test_parametrize_iterator.py::test2[param0] PASSED'
E           and: 'test_parametrize_iterator.py::test2[param1] PASSED'
E           and: 'test_parametrize_iterator.py::test_converted_to_str[1] PASSED'
E           and: 'test_parametrize_iterator.py::test_converted_to_str[2] PASSED'
E           and: ''
E           and: '============================== 6 passed in 0.04s ==============================='
E       remains unmatched: 'test_parametrize_iterator.py::test1[param0] PASSED'

(https://travis-ci.org/pytest-dev/pytest/jobs/611099976#L6281)

[blueyed]

For reference I'm planning to add idsetfn or something similar afterwards (blueyed#104).

[blueyed]

Having ids either as arg or kwarg is also not nice here.
Could be combined with _has_param_ids though at least.

[blueyed]

Not happy about having to return this here (for storing it in pytest_generate_tests then).

[RonnyPfannschmidt]

Solving the wrong problem at the wrong place feels like that

[blueyed]

The main problem here is passing args and kwargs, but not the mark.
This could be done instead here also - but the function can be used by itself also (without a mark), so I wanted to keep it apart. But having an optional store_resolved_ids_on_mark kwarg might suffice then.

Returning the generated ids is not too bad also after all, but I've felt that it might be limiting in the future, and should therefore return the generated calls also etc.

[RonnyPfannschmidt]

we might want to add a comment that this is intended to be a temporary hack to be resolved with object based marks

[blueyed]

👍
Will revisit before merging.

Thanks for the approval - I'm glad we could figure out something in the end.