From rpfannsc at redhat.com  Fri Feb  2 04:22:20 2018
From: rpfannsc at redhat.com (Ronny Pfannschmidt)
Date: Fri, 2 Feb 2018 10:22:20 +0100
Subject: [pytest-dev] Alias to parametrize
In-Reply-To: <20180131094252.GJ3489@beto>
References: <CA+RQFffMH4NH-u5EMgOx62tBU5bgQG-reC61UsnkMmZeDv+c2g@mail.gmail.com>
 <py3iefm8rqll.fsf@devork.be> <20180130085545.GX3489@beto>
 <py3i8tcesg2p.fsf@devork.be> <20180131094252.GJ3489@beto>
Message-ID: <CAA10jzMY3L8XddyH85ag_76fTHak5P70c8bVEpZDDaw+vHJzTw@mail.gmail.com>

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 <holger at merlinux.eu>:

> On Tue, Jan 30, 2018 at 22:22 -0800, Floris Bruynooghe wrote:
> > holger krekel <holger at merlinux.eu> writes:
> >
> > > On Mon, Jan 29, 2018 at 19:08 -0800, Floris Bruynooghe wrote:
> > >> Bruno Oliveira <nicoddemus at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180202/58d16321/attachment.html>

From florian.schulze at gmx.net  Fri Feb  2 05:26:16 2018
From: florian.schulze at gmx.net (Florian Schulze)
Date: Fri, 02 Feb 2018 11:26:16 +0100
Subject: [pytest-dev] Alias to parametrize
In-Reply-To: <CAA10jzMY3L8XddyH85ag_76fTHak5P70c8bVEpZDDaw+vHJzTw@mail.gmail.com>
References: <CA+RQFffMH4NH-u5EMgOx62tBU5bgQG-reC61UsnkMmZeDv+c2g@mail.gmail.com>
 <py3iefm8rqll.fsf@devork.be> <20180130085545.GX3489@beto>
 <py3i8tcesg2p.fsf@devork.be> <20180131094252.GJ3489@beto>
 <CAA10jzMY3L8XddyH85ag_76fTHak5P70c8bVEpZDDaw+vHJzTw@mail.gmail.com>
Message-ID: <2899FB31-1740-47E1-8048-411AA8699B9B@gmx.net>

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

From nicoddemus at gmail.com  Fri Feb  2 06:00:29 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 02 Feb 2018 11:00:29 +0000
Subject: [pytest-dev] Alias to parametrize
In-Reply-To: <CAA10jzMY3L8XddyH85ag_76fTHak5P70c8bVEpZDDaw+vHJzTw@mail.gmail.com>
References: <CA+RQFffMH4NH-u5EMgOx62tBU5bgQG-reC61UsnkMmZeDv+c2g@mail.gmail.com>
 <py3iefm8rqll.fsf@devork.be> <20180130085545.GX3489@beto>
 <py3i8tcesg2p.fsf@devork.be> <20180131094252.GJ3489@beto>
 <CAA10jzMY3L8XddyH85ag_76fTHak5P70c8bVEpZDDaw+vHJzTw@mail.gmail.com>
Message-ID: <CA+RQFffX3Cm-XqpaGRqn6V=zhRmN7MnsZs3r8_162fKE4XwM4A@mail.gmail.com>

On Fri, Feb 2, 2018 at 7:22 AM Ronny Pfannschmidt <rpfannsc at redhat.com>
wrote:

> 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
>

But if we will not be deprecating @pytest.mark.parametrize, why show a
warning at all?

IIUC we would be adding just an alias, with both 'parametrize' and
'apply_params' being considered correct, without one being recommended over
the other.

Cheers,
Bruno.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180202/cc8e0de4/attachment-0001.html>

From Hunter.Morgan at capitalone.com  Fri Feb  2 16:51:20 2018
From: Hunter.Morgan at capitalone.com (Morgan, Hunter)
Date: Fri, 2 Feb 2018 21:51:20 +0000
Subject: [pytest-dev] run id
Message-ID: <86BA8D63-4305-448D-B346-6C938D35FEC7@capitalone.com>

looking for a pytest run id for parameterizing fixture creation to avoid namespace collisions.
________________________________________________________

The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.


From me at the-compiler.org  Sat Feb  3 05:11:17 2018
From: me at the-compiler.org (Florian Bruhin)
Date: Sat, 3 Feb 2018 11:11:17 +0100
Subject: [pytest-dev] run id
In-Reply-To: <86BA8D63-4305-448D-B346-6C938D35FEC7@capitalone.com>
References: <86BA8D63-4305-448D-B346-6C938D35FEC7@capitalone.com>
Message-ID: <20180203100526.anx4pek5etqsdq6k@hooch.localdomain>

On Fri, Feb 02, 2018 at 09:51:20PM +0000, Morgan, Hunter via pytest-dev wrote:
> looking for a pytest run id for parameterizing fixture creation to
> avoid namespace collisions.

I don't follow. Can you please elaborate on what you want exactly and
why?

Florian

-- 
https://www.qutebrowser.org  | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072  | https://the-compiler.org/pubkey.asc
         I love long mails!  | https://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180203/e54b9b65/attachment.sig>

From aninhacostaribeiro at gmail.com  Wed Feb 14 04:07:36 2018
From: aninhacostaribeiro at gmail.com (Ana Ribeiro)
Date: Wed, 14 Feb 2018 10:07:36 +0100
Subject: [pytest-dev] Fwd: [Outreachy Community] PyCon CZ (Czech Republic)
 CFP deadline February 28
In-Reply-To: <464772212.1735789.1518581138482.JavaMail.zimbra@redhat.com>
References: <1700100419.1734602.1518579549648.JavaMail.zimbra@redhat.com>
 <464772212.1735789.1518581138482.JavaMail.zimbra@redhat.com>
Message-ID: <CAO-2QM6oMLeYcJiAGE3MH8ac3aNSEg5EOPC__LTQgS6sneNu8w@mail.gmail.com>

Maybe someone is interested on doing a presentation on pytest.

---------- Forwarded message ----------
From: Marina Zhurakhinskaya <marinaz at redhat.com>
Date: 2018-02-14 5:05 GMT+01:00
Subject: [Outreachy Community] PyCon CZ (Czech Republic) CFP deadline
February 28
To: community at lists.outreachy.org


Hi all,

PyCon CZ is looking for a wide range of talk and workshop proposals related
to Python. The conference will take place in Prague June 1-3, and the CFP
deadline is February 28.

If you've worked with Python, learn more and submit your proposal at
https://cz.pycon.org/2018/proposals/

Here is what they are looking for:

PyCon CZ attracts professional developers, test engineers and localization
and documentation specialists from all walks of life, including industry,
government and science, as well as enthusiasts and students. We?re looking
for proposals for presentations and workshops on any aspect of Python
programming, at all skill levels from novice to advanced.

Presentation subjects may range from reports on open source, academic or
commercial projects, or even tutorials and case studies. If a presentation
is interesting and useful to the Python community, it will be considered
for inclusion in the program. We're especially interested in short
presentations that will teach conference-goers something new and useful.
Can you show attendees how to use a module? Explore a Python language
feature? Package an application? Do you have inspiring lessons learned to
share?

Thanks,
Marina
_______________________________________________
Community mailing list
Community at lists.outreachy.org
https://lists.outreachy.org/cgi-bin/mailman/listinfo/community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180214/f8312dbe/attachment.html>

From nicoddemus at gmail.com  Tue Feb 20 16:11:35 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 20 Feb 2018 21:11:35 +0000
Subject: [pytest-dev] pytest 3.4.1 released
Message-ID: <CA+RQFfc6XVgQFrmgaX8qFYBH+ibfbjtt1FKBkubRCKg05DG00g@mail.gmail.com>

pytest 3.4.1 has just been released to PyPI.

This is a bug-fix release, being a drop-in replacement. To upgrade::

  pip install --upgrade pytest

The full changelog is available at
http://doc.pytest.org/en/latest/changelog.html.

Thanks to all who contributed to this release, among them:

* Aaron
* Alan Velasco
* Andy Freeland
* Brian Maissy
* Bruno Oliveira
* Florian Bruhin
* Jason R. Coombs
* Marcin Bachry
* Pedro Algarvio
* Ronny Pfannschmidt


Happy testing,
The pytest Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180220/6d86c86e/attachment.html>

From nicoddemus at gmail.com  Wed Feb 21 11:50:18 2018
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 21 Feb 2018 16:50:18 +0000
Subject: [pytest-dev] Use fixtures for parametrization discussion
Message-ID: <CA+RQFfd+kjs_4p1-WtnzdWCdupJ+_eb4bO5fKHo9z-Z7m5meNw@mail.gmail.com>

Hi everyone,

A coworker has once again asked me the age old question "how can I use a
fixture to parametrize a test?" and this motivated me to write
https://github.com/pytest-dev/pytest/issues/3244 in order to find a
solution to this.

It would be great if people can participate in that discussion.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180221/bf2a6fbe/attachment.html>