Add parameterize() as an alias for parametrize()

[alanbato]

As per the suggestion in this tweet.

I'm not sure how to test it, though.
I'm not even sure if this behavior is desired by the pytest team.

But if someone thinks this is a good idea: worry not, for it is here.
🐍

[The-Compiler]

I'd rather not to be honest 😉 I think the warning is good enough already, and I think it's good to enforce this to be consistent across testsuites.

[nicoddemus]

I'm -0 on this for the same reason mentioned by @The-Compiler, I think the warning is a good enough approach and enforces consistency. Also I might be wrong but I don't seem much aliases because of differences in US vs UK spellings (for example color vs colour) in other libraries.

Having said all that if more people really want this I'm not opposed at all, after all it is not a big maintenance problem or anything.

[alanbato]

I figured you were going for consistency when I saw the warning. But like @nicoddemus said, it's not that big of a chance and introduces almost no new functionality. So, if it gains enough traction you already have something started :) 🚜

Moreover, if you want consistency in the codebase, I should let you know there is an occurrence of the parameterize spelling in mark.py. But I think since it's an internal function, users are not exposed to that way of spelling it. 😃

[fschulze]

Either there should be no alternate spellings (the s variants) or this should be accepted for consistency with the other variants. Since the other variants already exist and removing them would break things, I'd say this should be accepted. I'm pretty sure I stumbled over this myself a few times.

[nicoddemus]

Since the other variants already exist and removing them would break things, I'd say this should be accepted.

Which variants you mean? The one @alanbato mentions is in an internal function, which should not break anything if renamed.

[fschulze]

@nicoddemus sorry, I misread the source alt_spellings = ['parameterize', 'parametrise', 'parameterise'] . It creates a warning to use the correct spelling.
I change my vote to -1 then.

[RonnyPfannschmidt]

i'd prefer to fix the spelling for the internal helper, perhaps even move it out of the class

[okken]

As I was the one requesting this functionality, I’d vote for its inclusion.

I don’t buy the color/colour argument. Americans are used to this spelling difference. However, I have to explicitly warn everyone I teach about the parametrize spelling because most people don’t know that’s a thing.

If it does not impose a performance penalty or maintenance cost penalty, then removing one barrier for new users seems worth it to me.

However, I’m not going to lose any sleep over it if it gets rejected.

[nicoddemus]

If we are to include this, I prefer if you would just create an actual alias in the class:

parameterize = parametrize

While mentioning in the docs that parameterize is a valid alias; we don't want to have the documentation duplicated.

[alanbato]

That does seem like a more elegant solution. Should it be placed below the parametrize definition with a comment stating it's an alias?

[nicoddemus]

Sounds good.

Please add a test which uses the new spelling as well.

[alanbato]

I'm having trouble getting the test to work, so far I have this:

def test_parameterize(self, testdir):
    testdir.makepyfile("""
        import pytest
        @pytest.mark.parameterize("foo", [1, 2, 3])
        def test_foo(foo):
            assert foo in [1, 2, 3]
    """)
    reprec = testdir.inline_run()
    reprec.assertoutcome(passed=3)

And it complains about fixture 'value' not found.
If I use parametrize instead, it does work.
What am I doing wrong? 🤔

[nicoddemus]

value? Perhaps you mean foo? If that's the case I think you also need to handle that name here:

pytest/_pytest/fixtures.py

Line 1054 in 3bc7ced

parametrize_func = getattr(metafunc.function, 'parametrize', None)

Perhaps something like: getattr(metafunc.function, 'parametrize', None) or getattr(metafunc.function, 'parameterize', None) (ugh).

Otherwise please post the full error message.

[alanbato]

Yes, I meant foo. 😅 (I was also testing on a separate file where I used value instead)

I changed it but still got the same error, posting the full error below:

Error

==================================== ERRORS ====================================
__________________________ ERROR at setup of test_foo __________________________
file /tmp/pytest-of-alanbato/pytest-30/test_parameterize0/test_parameterize.py, line 2
  @pytest.mark.parameterize("foo", [1, 2, 3])
  def test_foo(foo):
E       fixture 'foo' not found
>       available fixtures: cache, capfd, capfdbinary, caplog, capsys, capsysbinary, doctest_namespace, monkeypatch, pytestconfig, record_xml_property, recwarn, tmpdir, tmpdir_factory
>       use 'pytest --fixtures [testpath]' for help on them.

/tmp/pytest-of-alanbato/pytest-30/test_parameterize0/test_parameterize.py:2

[nicoddemus]

You applied the change I mentioned in fixtures.py right? Hmm so it must be missing somewhere else... not sure where, a quick search didn't turn up anything obvious.

But I suggest for you to not spend too much time on this until we decide for sure if we want to merge this or not. 😅

[The-Compiler]

For reference, here's what happens currently:

======================================== test session starts =========================================
platform linux -- Python 3.6.4, pytest-3.3.2, py-1.5.0, pluggy-0.6.0
rootdir: /home/florian/tmp/pytest, inifile:
collected 0 items / 1 errors                                                                         

=============================================== ERRORS ===============================================
____________________________________ ERROR collecting test_foo.py ____________________________________
/usr/lib/python3.6/site-packages/pluggy/__init__.py:617: in __call__
    return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
/usr/lib/python3.6/site-packages/pluggy/__init__.py:222: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3.6/site-packages/pluggy/__init__.py:216: in <lambda>
    firstresult=hook.spec_opts.get('firstresult'),
/usr/lib/python3.6/site-packages/_pytest/python.py:192: in pytest_pycollect_makeitem
    res = list(collector._genfunctions(name, obj))
/usr/lib/python3.6/site-packages/_pytest/python.py:370: in _genfunctions
    self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3.6/site-packages/pluggy/__init__.py:617: in __call__
    return self._hookexec(self, self._nonwrappers + self._wrappers, kwargs)
/usr/lib/python3.6/site-packages/pluggy/__init__.py:222: in _hookexec
    return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3.6/site-packages/pluggy/__init__.py:216: in <lambda>
    firstresult=hook.spec_opts.get('firstresult'),
/usr/lib/python3.6/site-packages/_pytest/python.py:111: in pytest_generate_tests
    raise MarkerError(msg.format(metafunc.function.__name__, attr))
E   _pytest.mark.MarkerError: test_x has 'parameterize', spelling should be 'parametrize'
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
====================================== 1 error in 0.14 seconds =======================================

That exception should probably be less intimidating (less verbose), but other than that, it clearly says what's wrong and what to do about it.

Some elaborations on why I think this is a bad idea:

• As a project maintainer, I want to be consistent in what's used in my project. With the alias, I either have to check for a very similar but inconsistent spelling by hand, or I need to configure a linter (or maybe even write a plugin?) to disallow it.
• As a contributor to various open-source projects which might like consistency as well, I now first have to check which spelling they use before I can start contributing tests. That alone is a bigger hurdle than reading the message above and adjusting the spelling, IMHO. I also need to double-check that I used the right one because I'm used to typing "parametrize".
• Someone new to pytest, I'd imagine, sees both spellings in various projects and wonders what the difference is. They now have to check the documentation to find out it's both really the same thing. Now they have to decide which one to use in their own projects. Again, that alone is a bigger hurdle than having one right way.
• When teaching pytest (or for that matter, writing a book about it), I now have to explain both spellings, as they both are used in the wild, and explain that they're actually the same. It's not much extra complexity, but it's there, and it doesn't need to be.

[The-Compiler]

cc @pfctdayelise who (in #463) went for a warning instead of an alias like @bgr originally proposed 😉

[grizz]

Against this change, for the reasons @The-Compiler listed. The internal naming should be fixed to be consistent.

[nicoddemus]

Guys I think overall the reaction has been a 👎 so I'm closing this. Anyways thanks everyone for joining the discussion, if nothing else at least now people are armed with arguments to justify the spelling (and there's a thread to be pointed to).