On Tue, Jan 30, 2018 at 22:22 -0800, Floris Bruynooghe wrote:
> 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().
I like metafunc.apply_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.
For past renamings we simply changed the docs to use the preferred version
and maybe added a note about the old spelling. For example, before
``metafunc.parametrize`` was introduced ~6y ago pytest docs advertised
``metafunc.addcall`` which still works today. It was finally deprecated
in pytest-3.3 and its removal will probably still break existing code.
However, here keeping backward-compat compatibility complicates the
intricate parametrization/fixture interaction implementation. Therefore
I guess it's warranted to remove it eventually because it relaxes refactoring
constraints. By comparison, renaming parametrize() to apply_params() is
a trivial thing to support in a backward compatible way (``parametrize =
apply_params``).
IMHO the new spelling should be part of core proper and could even come
with a 3.5 (or 3.6 ...) because it doesn't break anything.
holger
> 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
