holger krekel <hol...@merlinux.eu> writes:
> On Mon, Jan 29, 2018 at 19:08 -0800, Floris Bruynooghe wrote:
>> Bruno Oliveira <nicodde...@gmail.com> writes:
>> > A PR[1] has been submitted which adds `parameterize` as an alias to
>> > `parametrize`. Florian Bruhin and I are not very keen to the idea given
>> > that there is an explicit warning for it already and having different names
>> > to the same thing reduces consistency across test suites.
>>
>> So I've recently finished a (toy) plugin which I've been intending to
>> release as pytest-parawtf. It's currently in the legal machine of my
>> employer for me to hopefully be able to release unrestricted. You can
>> probably guess what it does from the name, but it basically allows a few
>> misspellings in all locations. I actually considered allowing anything
>> matching the ``param*`` wildcard but thought while fun it would probably
>> stop people from using it.
>>
>> However the serious note in that plugin is that I think it makes sense
>> to use ``params``. My reasoning is that it's easy to spell and already
>> used for fixtures: ``@pytest.fixture(params=[0, 1])``. So why not
>> everywhere else: ``@pytest.mark.params('a', [0, 1])``,
>> ``metafunc.params(...)``. So to be honest I think we should migrate to
>> that and still disallow the other variants. It would mean I don't get
>> to release my fun plugin but whatever.
>
> i initially meant to write my skepticism wrt to going the
> "alternative spellings" route but FWIW i do like "params" as it also matches
> accessing a parameter via "request.param" inside fixture functions. For
> ``metafunc.X`` i rather expect X to be a verb, however. /me fiddles with
> the parameters of what he supposes is a time-machine ...
>
> That being said i don't like the idea of making tons of existing code
> throw warnings, let alone having "pytest.mark.parametrize" erroring out
> in future pytest versions. I guess i am aware of too many existing code
> bases (and written and printed tutorials and books) which would
> suffer. Independently from the question at hand I recommend to be
> careful with the notion of "people can just rename their code".
For metafunc having a verb sort of makes sense. But also the
consistency argument is strong. You could try to go the .apply_params()
or something similar route I guess but not sure I'd prefer this over the
bare .params().
Also, I don't think there is any reason to start issuing warnings for
something like this. We can and should support parametrize for eternity
without ever issuing warnings or anything like that. Only a note in the
documentation to suggest one may prefer to use the params variant in new
code if one doesn't feel strongly themselves. Alternatively we could
leave it as a plugin and refer to that in the docs. If it proves
popular (not sure how you can know that these days, but anyway) then it
could still be merged into the core at some point.
On that last thing there is one caveat, hinted at by Brian. The plugin
does not play nice. I don't have the code with me as I'm traveling but
IIRC it uses at least one underscored method/attribute and even
everything else it does is outright horrible and can't be reasonably
considered part of the public pytest API.
Cheers,
Floris
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
