HI,
i also like apply_params, it well in place with my desire of a more
complete rename instead of just cutting it short.
+1
for eternal old api's i would like to introduce a warning which is per
default filtered (like a future-warning), simply so plugin authors can have
a advised way of keeping up with core even if we keep some old things in
place for users
-- Ronny
2018-01-31 10:42 GMT+01:00 holger krekel <hol...@merlinux.eu>:
> 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
>
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
