Re: [pytest-dev] Alias to parametrize

[Florian Schulze]

On 2 Feb 2018, at 10:22, Ronny Pfannschmidt wrote:


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


Hidden things are not seen (duh). Before deprecation warnings were 
shown, no one cared. I think it's better if it's easy for people to hide 
warnings in their own code bases.


Regards,
Florian Schulze
___
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev

Re: [pytest-dev] Alias to parametrize

[Ronny Pfannschmidt]

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 :

> On Tue, Jan 30, 2018 at 22:22 -0800, Floris Bruynooghe wrote:
> > holger krekel  writes:
> >
> > > On Mon, Jan 29, 2018 at 19:08 -0800, Floris Bruynooghe wrote:
> > >> Bruno Oliveira  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
>