Hello all,
I kinda feel bad that this has turned into kind-of an ordeal.
Or at least it seems like it has.
I'm rather rooting for the "params" version, and agree with Floris that
"parametrize" should be supported for eternity.
This is not something urgent, of course.
One option is to implement the params version on a branch, and let everyone
who cares know where it is.
We could try it out, play with it, write up a few examples and see how it
looks, try explaining it, etc.
Then make a decision of whether it's worth including or not.
WRT the plugin version, if it would end up being an ugly thing that
shouldn't be used as an example for others, then it's probably not a good
idea.
In any case, I admire all of you and will stand behind whatever decision is
made.
Cheers,
Brian
On Tue, Jan 30, 2018 at 10:22 PM, Floris Bruynooghe <f...@devork.be> 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().
>
> 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
>
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
