From nicoddemus at gmail.com Thu Jan 4 17:44:49 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 04 Jan 2018 22:44:49 +0000 Subject: [pytest-dev] pytest 3.3.2 Message-ID: pytest 3.3.2 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: * Anthony Sottile * Antony Lee * Austin * Bruno Oliveira * Florian Bruhin * Floris Bruynooghe * Henk-Jaap Wagenaar * Jurko Gospodneti? * Ronny Pfannschmidt * Srinivas Reddy Thatiparthy * Thomas Hisch Happy testing, The pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Jan 4 20:12:22 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Fri, 05 Jan 2018 01:12:22 +0000 Subject: [pytest-dev] Proposal: use milestones again for features/deprecations/removals Message-ID: Hi, We used milestones in the past to track what would go in each release, including bugs and new features, but we have not been using them anymore and I think the reason is because we never usually kept that promise: if we deemed a release should happen soon we just moved all issues forward or removed the milestone from them altogether. I propose we start using milestones again, but only for two reasons: * **internal** planning of new features: we should use milestones as an internal guide of what *should* go into the next feature release. This is not a promise to users, only for us to manage what we think should go into the next release core developer's time allowing. For example, in my mind we should change the default logging options [1], but this is not really defined anywhere except in my head. I would like to use milestones to track that intent. * **promise** of deprecation and removal of old features: we have been using a manual deprecation roadmap [2], but the question of how to keep issues in sync has been nagging in the back of my head. We should track deprecation and removals in the milestones, but we must be sure to followup with them before a feature release is complete. It is important to follow with our policy of deprecation/two minor issues/removal. The idea is to, before a feature release, we check the the issues assigned to that milestone: * for open features, we can decide to ping the developer if they want some more time to get that into that next feature release, otherwise we move it to the next milestone; * for open deprecation/removal issues, we have to make sure to close them before moving with the release. IMHO, milestones should be created only for feature releases; milestones for minor releases don't make much sense in our current development methodology: we can issue bug-fix releases as quickly as we want/need to, so no feature release should really be blocked by a bug, we can always issue a bug-fix right after a certain bug is dealt with. This is an attempt to help our planning and strengthen our deprecation/removal policy. Thoughts? [1] https://github.com/pytest-dev/pytest/issues/3013 [2] https://docs.pytest.org/en/latest/backwards-compatibility.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpfannsc at redhat.com Mon Jan 8 02:43:05 2018 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Mon, 8 Jan 2018 08:43:05 +0100 Subject: [pytest-dev] Proposal: use milestones again for features/deprecations/removals In-Reply-To: References: Message-ID: +1 from me 2018-01-05 2:12 GMT+01:00 Bruno Oliveira : > Hi, > > We used milestones in the past to track what would go in each release, > including bugs and new features, but we have not been using them anymore > and I think the reason is because we never usually kept that promise: if we > deemed a release should happen soon we just moved all issues forward or > removed the milestone from them altogether. > > I propose we start using milestones again, but only for two reasons: > > * **internal** planning of new features: we should use milestones as an > internal guide of what *should* go into the next feature release. This is > not a promise to users, only for us to manage what we think should go into > the next release core developer's time allowing. For example, in my mind we > should change the default logging options [1], but this is not really > defined anywhere except in my head. I would like to use milestones to track > that intent. > > * **promise** of deprecation and removal of old features: we have been > using a manual deprecation roadmap [2], but the question of how to keep > issues in sync has been nagging in the back of my head. We should track > deprecation and removals in the milestones, but we must be sure to followup > with them before a feature release is complete. It is important to follow > with our policy of deprecation/two minor issues/removal. > > The idea is to, before a feature release, we check the the issues assigned > to that milestone: > > * for open features, we can decide to ping the developer if they want > some more time to get that into that next feature release, otherwise we > move it to the next milestone; > * for open deprecation/removal issues, we have to make sure to close them > before moving with the release. > > IMHO, milestones should be created only for feature releases; milestones > for minor releases don't make much sense in our current development > methodology: we can issue bug-fix releases as quickly as we want/need to, > so no feature release should really be blocked by a bug, we can always > issue a bug-fix right after a certain bug is dealt with. > > This is an attempt to help our planning and strengthen our > deprecation/removal policy. > > Thoughts? > > [1] https://github.com/pytest-dev/pytest/issues/3013 > [2] https://docs.pytest.org/en/latest/backwards-compatibility.html > > > > _______________________________________________ > 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: From edgar.ostrowski at gmail.com Mon Jan 8 07:32:24 2018 From: edgar.ostrowski at gmail.com (Edgar Ostrowski) Date: Mon, 8 Jan 2018 13:32:24 +0100 Subject: [pytest-dev] Parametrizing dependent fixtures Message-ID: Hello pytest team! Recently I've came across a talk about pytest by Gabe Hollombe https://youtu.be/RcN26hznmk4 One thing that he mentioned really caught my eye. Close to the end of the talk he speaks about parametrizing dependent fixtures by using @pytest.mark.parametrize. Here is link to that moment: https://youtu.be/RcN26hznmk4?t=2397 This looks like a very helpful feature. I tired it out on my own and yes it works: https://gist.github.com/Kanguros/e455901f5b940098d1d18628a27cbdb2 Unfortunately I could not find anything about this in the docs. Or maybe I'm just reading them in the wrong way. Anyway I would like to confirm that this is valid way of using the parametrize marker. Does this have any drawbacks? Is it reliable? Up till now I've only been aware of parametrizing fixtures using @pytest.fixture(params=...) Keep up the great work and thank you. Edgar -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 8 08:07:36 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 08 Jan 2018 13:07:36 +0000 Subject: [pytest-dev] Parametrizing dependent fixtures In-Reply-To: References: Message-ID: Hi Edgar, On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski wrote: > Anyway I would like to confirm that this is valid way of using the > parametrize marker. > I did not look at the video yet, but fixture parametrization only works by using @pytest.fixture(params=...). Markers don't do anything when applying to fixtures. Hope that clarifies things! Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpfannsc at redhat.com Mon Jan 8 08:36:05 2018 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Mon, 8 Jan 2018 14:36:05 +0100 Subject: [pytest-dev] Parametrizing dependent fixtures In-Reply-To: References: Message-ID: Hi, my understanding is, that the direct parametrization replaces the fixture lookup for the involved tests, which is not a planned "feature" per se, but still a neat tool to have -- Ronny 2018-01-08 14:07 GMT+01:00 Bruno Oliveira : > Hi Edgar, > > On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski > wrote: > >> Anyway I would like to confirm that this is valid way of using the >> parametrize marker. >> > > I did not look at the video yet, but fixture parametrization only works by > using @pytest.fixture(params=...). Markers don't do anything when applying > to fixtures. > > Hope that clarifies things! > > Cheers, > Bruno. > > _______________________________________________ > 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: From davin.geiger at intel.com Mon Jan 8 08:41:44 2018 From: davin.geiger at intel.com (Geiger, Davin) Date: Mon, 8 Jan 2018 13:41:44 +0000 Subject: [pytest-dev] Parametrizing dependent fixtures In-Reply-To: References: Message-ID: A disadvantage could be that the fixture code (of the depended fixture) will not be executed. This means no preparation and cleanup steps are executed. From: pytest-dev [mailto:pytest-dev-bounces+davin.geiger=intel.com at python.org] On Behalf Of Ronny Pfannschmidt Sent: Monday, January 8, 2018 14:36 To: Bruno Oliveira Cc: Edgar Ostrowski ; pytest-dev Subject: Re: [pytest-dev] Parametrizing dependent fixtures Hi, my understanding is, that the direct parametrization replaces the fixture lookup for the involved tests, which is not a planned "feature" per se, but still a neat tool to have -- Ronny 2018-01-08 14:07 GMT+01:00 Bruno Oliveira >: Hi Edgar, On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski > wrote: Anyway I would like to confirm that this is valid way of using the parametrize marker. I did not look at the video yet, but fixture parametrization only works by using @pytest.fixture(params=...). Markers don't do anything when applying to fixtures. Hope that clarifies things! Cheers, Bruno. _______________________________________________ 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 Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Mon Jan 8 15:32:58 2018 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 08 Jan 2018 21:32:58 +0100 Subject: [pytest-dev] Parametrizing dependent fixtures In-Reply-To: References: Message-ID: <87y3l8xf9h.fsf@powell.devork.be> Curious. I'm rather reluctant to tell people to use or rely on this however. Which I guess is the actual question that was asked. ;-) To me this seems like an implementation detail of the mark.parametrize decorator. Besides, is it really a good idea to make your parametrisation so indirect? I think you're breaking the abstraction fixtures are trying to create for you: You request the fixture and you should not be caring about how to create it, about whether is uses other fixtures to create itself and whether or not it is parametrised. I know there are exceptions to all rules, but it's a good design consideration to think about before constructing many intricately and tightly coupled dependencies. Regards, Floris "Geiger, Davin" writes: > A disadvantage could be that the fixture code (of the depended fixture) will not be executed. > > This means no preparation and cleanup steps are executed. > > From: pytest-dev [mailto:pytest-dev-bounces+davin.geiger=intel.com at python.org] On Behalf Of Ronny Pfannschmidt > Sent: Monday, January 8, 2018 14:36 > To: Bruno Oliveira > Cc: Edgar Ostrowski ; pytest-dev > Subject: Re: [pytest-dev] Parametrizing dependent fixtures > > Hi, > > my understanding is, that the direct parametrization replaces the fixture lookup for the involved tests, > which is not a planned "feature" per se, but still a neat tool to have > > -- Ronny > > 2018-01-08 14:07 GMT+01:00 Bruno Oliveira >: > Hi Edgar, > > On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski > wrote: > Anyway I would like to confirm that this is valid way of using the parametrize marker. > > I did not look at the video yet, but fixture parametrization only works by using @pytest.fixture(params=...). Markers don't do anything when applying to fixtures. > > Hope that clarifies things! > > Cheers, > Bruno. > > _______________________________________________ > 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 > Intel Deutschland GmbH > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Christian Lamprechter > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From edgar.ostrowski at gmail.com Tue Jan 9 05:15:41 2018 From: edgar.ostrowski at gmail.com (Edgar Ostrowski) Date: Tue, 9 Jan 2018 11:15:41 +0100 Subject: [pytest-dev] Parametrizing dependent fixtures In-Reply-To: <87y3l8xf9h.fsf@powell.devork.be> References: <87y3l8xf9h.fsf@powell.devork.be> Message-ID: Thank you guys for answering my question. Everything is clear now. I was thinking that maybe this was missing from the documentation. But it makes no sens add it since it not a real feature. Let's just hope that people don't using it too extensively. Thank you, keep up the good work. Edgar 2018-01-08 21:32 GMT+01:00 Floris Bruynooghe : > Curious. I'm rather reluctant to tell people to use or rely on this > however. Which I guess is the actual question that was asked. ;-) To > me this seems like an implementation detail of the mark.parametrize > decorator. > > Besides, is it really a good idea to make your parametrisation so > indirect? I think you're breaking the abstraction fixtures are trying > to create for you: You request the fixture and you should not be caring > about how to create it, about whether is uses other fixtures to create > itself and whether or not it is parametrised. I know there are > exceptions to all rules, but it's a good design consideration to think > about before constructing many intricately and tightly coupled > dependencies. > > > Regards, > Floris > > > "Geiger, Davin" writes: > > > A disadvantage could be that the fixture code (of the depended fixture) > will not be executed. > > > > This means no preparation and cleanup steps are executed. > > > > From: pytest-dev [mailto:pytest-dev-bounces+davin.geiger= > intel.com at python.org] On Behalf Of Ronny Pfannschmidt > > Sent: Monday, January 8, 2018 14:36 > > To: Bruno Oliveira > > Cc: Edgar Ostrowski ; pytest-dev < > pytest-dev at python.org> > > Subject: Re: [pytest-dev] Parametrizing dependent fixtures > > > > Hi, > > > > my understanding is, that the direct parametrization replaces the > fixture lookup for the involved tests, > > which is not a planned "feature" per se, but still a neat tool to have > > > > -- Ronny > > > > 2018-01-08 14:07 GMT+01:00 Bruno Oliveira icoddemus at gmail.com>>: > > Hi Edgar, > > > > On Mon, Jan 8, 2018 at 10:32 AM Edgar Ostrowski < > edgar.ostrowski at gmail.com> wrote: > > Anyway I would like to confirm that this is valid way of using the > parametrize marker. > > > > I did not look at the video yet, but fixture parametrization only works > by using @pytest.fixture(params=...). Markers don't do anything when > applying to fixtures. > > > > Hope that clarifies things! > > > > Cheers, > > Bruno. > > > > _______________________________________________ > > 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 > > Intel Deutschland GmbH > > Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany > > Tel: +49 89 99 8853-0, www.intel.de > > Managing Directors: Christin Eisenschmid, Christian Lamprechter > > Chairperson of the Supervisory Board: Nicole Lau > > Registered Office: Munich > > Commercial Register: Amtsgericht Muenchen HRB 186928 > > _______________________________________________ > > pytest-dev mailing list > > pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnilrets at gmail.com Fri Jan 12 18:51:03 2018 From: gnilrets at gmail.com (Sterling Paramore) Date: Fri, 12 Jan 2018 15:51:03 -0800 Subject: [pytest-dev] Custom test collection with fixtures Message-ID: I'm trying to build a plugin that will do something "special" with test functions that are prefixed with "case_". However, I'm having trouble collecting those and using them with fixtures. in conftest.py I have def pytest_pycollect_makeitem(collector, name, obj): if inspect.isfunction(obj) and (name.startswith('case_'): Function = collector._getcustomclass("Function") return Function(name, parent=collector) and in test_mything.py I have: class TestSomething(): @pytest.fixture def scenario(self): pass def case_1(self, scenario): pass But when I run the test, I get an error "TypeError: case_1() missing 1 required positional argument: 'scenario'" How can I create the item so that it runs with the specific fixtures? Thanks, Sterling -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 15 09:24:33 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 15 Jan 2018 14:24:33 +0000 Subject: [pytest-dev] Custom test collection with fixtures In-Reply-To: References: Message-ID: Hi Sterling, Looking at pytest?s code , it seems it also needs a fixtureinfo object: yield Function(name, parent=self, fixtureinfo=fixtureinfo) This feels a little more complicate than it should to me, but I guess that?s how things stand currently. Sorry for not being able to help more, I?m in a rush today. Cheers, ? On Fri, Jan 12, 2018 at 9:51 PM Sterling Paramore wrote: > I'm trying to build a plugin that will do something "special" with test > functions that are prefixed with "case_". However, I'm having trouble > collecting those and using them with fixtures. > > in conftest.py I have > > def pytest_pycollect_makeitem(collector, name, obj): > if inspect.isfunction(obj) and (name.startswith('case_'): > Function = collector._getcustomclass("Function") > return Function(name, parent=collector) > > and in test_mything.py I have: > > class TestSomething(): > @pytest.fixture > def scenario(self): > pass > > def case_1(self, scenario): > pass > > But when I run the test, I get an error "TypeError: case_1() missing 1 > required positional argument: 'scenario'" > > How can I create the item so that it runs with the specific fixtures? > > Thanks, > Sterling > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Jan 18 02:53:32 2018 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 18 Jan 2018 08:53:32 +0100 Subject: [pytest-dev] [proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks In-Reply-To: <1512750992.3489.10.camel@ronnypfannschmidt.de> References: <1512750992.3489.10.camel@ronnypfannschmidt.de> Message-ID: <20180118075332.wfggdinmtsyywva4@hooch.localdomain> Hey, GitMate seemed quite useful so far! However, the "the contributor most likely able to help you" messages seemed quite a lot of noise to me. Also, they only pinged people who are subscribed to the repository anyways, and are already doing a lot of work either way. I took the freedom to turn that off. Maybe it makes sense to turn it on and blacklist core contributors (as those watch the repo presumably) so it can highlight the right people in cases where there's really another contributor who developed a certain feature. However, in the qutebrowser repo, it just started highlighting people with seemingly no connection to the issues ;-) 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: From rpfannsc at redhat.com Thu Jan 18 04:39:24 2018 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Thu, 18 Jan 2018 10:39:24 +0100 Subject: [pytest-dev] [proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks In-Reply-To: <20180118075332.wfggdinmtsyywva4@hooch.localdomain> References: <1512750992.3489.10.camel@ronnypfannschmidt.de> <20180118075332.wfggdinmtsyywva4@hooch.localdomain> Message-ID: thanks for that feedback, i presume you also fed it to git-mate since they are eager to fix their product -- Ronny 2018-01-18 8:53 GMT+01:00 Florian Bruhin : > Hey, > > GitMate seemed quite useful so far! However, the "the contributor most > likely able to help you" messages seemed quite a lot of noise to me. > Also, they only pinged people who are subscribed to the repository > anyways, and are already doing a lot of work either way. > > I took the freedom to turn that off. Maybe it makes sense to turn it on > and blacklist core contributors (as those watch the repo presumably) so > it can highlight the right people in cases where there's really another > contributor who developed a certain feature. However, in the qutebrowser > repo, it just started highlighting people with seemingly no connection > to the issues ;-) > > 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/ > > _______________________________________________ > 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: From nicoddemus at gmail.com Sat Jan 20 10:51:40 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 20 Jan 2018 15:51:40 +0000 Subject: [pytest-dev] codespeak.net down Message-ID: Hi everyone, >From https://github.com/pytest-dev/pytest-xdist/issues/258, codespeak.net is down. Can anybody with access bring it back up? Alternatively we might consider moving its documentation to ReadTheDocs. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Sun Jan 21 00:58:02 2018 From: holger at merlinux.eu (holger krekel) Date: Sun, 21 Jan 2018 06:58:02 +0100 Subject: [pytest-dev] codespeak.net down In-Reply-To: References: Message-ID: <20180121055802.GU16901@beto> Hi Bruno, On Sat, Jan 20, 2018 at 15:51 +0000, Bruno Oliveira wrote: > Hi everyone, > > From https://github.com/pytest-dev/pytest-xdist/issues/258, codespeak.net > is down. Can anybody with access bring it back up? codespeak.net is not down but indeed the underlying infrastructure changed. I regenerated docs and pushed them to the new codespeak.net site (which also has proper https). > Alternatively we might consider moving its documentation to ReadTheDocs. yes, actually https://execnet.readthedocs.io is already there and up to date ASFAIK. i added ronny and you to be sure it's not just me who can change things there. holger From nicoddemus at gmail.com Sun Jan 21 06:42:25 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sun, 21 Jan 2018 11:42:25 +0000 Subject: [pytest-dev] codespeak.net down In-Reply-To: <20180121055802.GU16901@beto> References: <20180121055802.GU16901@beto> Message-ID: On Sun, Jan 21, 2018 at 3:58 AM holger krekel wrote: > Hi Bruno, > > On Sat, Jan 20, 2018 at 15:51 +0000, Bruno Oliveira wrote: > > Hi everyone, > > > > From https://github.com/pytest-dev/pytest-xdist/issues/258, > codespeak.net > > is down. Can anybody with access bring it back up? > > codespeak.net is not down but indeed the underlying infrastructure > changed. > I regenerated docs and pushed them to the new codespeak.net site > (which also has proper https). > Thanks Holger! Cheers, -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Mon Jan 29 05:20:38 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 29 Jan 2018 10:20:38 +0000 Subject: [pytest-dev] Alias to parametrize Message-ID: Hi all, 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. I'm sending an email here because I suppose more people read the mailing list than watch the PRs and the discussions there. It would be good if more people commented/voted on the issue before we reach a conclusion. [1] https://github.com/pytest-dev/pytest/pull/3159 Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Mon Jan 29 22:08:06 2018 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 29 Jan 2018 19:08:06 -0800 Subject: [pytest-dev] Alias to parametrize In-Reply-To: References: Message-ID: Hi, 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. Regards, Floris From grizz at 20c.com Tue Jan 30 00:28:29 2018 From: grizz at 20c.com (Matt Griswold) Date: Tue, 30 Jan 2018 05:28:29 +0000 Subject: [pytest-dev] Alias to parametrize In-Reply-To: References: Message-ID: <20180130052829.1379bbea@x0r> * Floris Bruynooghe [180129 19:08 -0800]: > 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. That makes a lot of sense to me, although I'm not a pytest developer and have no idea what the pytest rules for making backward incompatible changes are. After reading this thread, I chimed in on GitHub -- aliases are almost never a good idea, but the fact that there's an alt_spellings list in the code means that it really should just be renamed. This should be as simple as a deprecation warning, time period, and users doing a s/parametrize/params/. Cheers From rpfannsc at redhat.com Tue Jan 30 02:05:17 2018 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Tue, 30 Jan 2018 08:05:17 +0100 Subject: [pytest-dev] Alias to parametrize In-Reply-To: <20180130052829.1379bbea@x0r> References: <20180130052829.1379bbea@x0r> Message-ID: the alt_spellings is actually a list of wrong spellings that triggers errors - the reason being that the word as different spellings in british and american English if we actually change the word i would like to see something completely different, not just some short-cutting -- Ronny 2018-01-30 6:28 GMT+01:00 Matt Griswold : > * Floris Bruynooghe [180129 19:08 -0800]: > > 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. > > That makes a lot of sense to me, although I'm not a pytest developer > and have no idea what the pytest rules for making backward incompatible > changes are. > > After reading this thread, I chimed in on GitHub -- aliases are almost > never a good idea, but the fact that there's an alt_spellings list in > the code means that it really should just be renamed. This should be as > simple as a deprecation warning, time period, and users doing a > s/parametrize/params/. > > Cheers > _______________________________________________ > 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: From grizz at 20c.com Tue Jan 30 02:29:00 2018 From: grizz at 20c.com (Matt Griswold) Date: Tue, 30 Jan 2018 07:29:00 +0000 Subject: [pytest-dev] Alias to parametrize In-Reply-To: References: <20180130052829.1379bbea@x0r> Message-ID: <20180130072900.1626b6a1@x0r> * Ronny Pfannschmidt [180130 08:05 +0100]: > the alt_spellings is actually a list of wrong spellings that triggers > errors - the reason being that the word as different spellings in > british and american English The whole list is, yes -- in the case of that PR, it's making an alias for two American English spellings of the same word. My point was that if it's causing enough confusion to warrant code that checks for other spellings to give a warning, it should be changed. > if we actually change the word i would like to see something > completely different, not just some short-cutting I think params is a good choice, as it's a common abbreviation and is used in other places in pytest. What would you suggest? From holger at merlinux.eu Tue Jan 30 03:55:45 2018 From: holger at merlinux.eu (holger krekel) Date: Tue, 30 Jan 2018 09:55:45 +0100 Subject: [pytest-dev] Alias to parametrize In-Reply-To: References: Message-ID: <20180130085545.GX3489@beto> 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". holger From nicoddemus at gmail.com Tue Jan 30 17:18:17 2018 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 30 Jan 2018 22:18:17 +0000 Subject: [pytest-dev] pytest 3.4.0 released! Message-ID: The pytest team is proud to announce the 3.4.0 release! pytest is a mature Python testing tool with more than a 1600 tests against itself, passing on many different interpreters and platforms. This release contains considerable improvements to the logging facilities as well as other fixes and improvements, so users are encouraged to take a look at the CHANGELOG: http://doc.pytest.org/en/latest/changelog.html For complete documentation, please visit: http://docs.pytest.org As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Aaron * Alan Velasco * Anders Hovm?ller * Andrew Toolan * Anthony Sottile * Aron Coyle * Brian Maissy * Bruno Oliveira * Cyrus Maden * Florian Bruhin * Henk-Jaap Wagenaar * Ian Lesperance * Jon Dufresne * Jurko Gospodneti? * Kate * Kimberly * Per A. Brodtkorb * Pierre-Alexandre Fonta * Raphael Castaneda * Ronny Pfannschmidt * ST John * Segev Finer * Thomas Hisch * Tzu-ping Chung * feuillemorte Happy testing, The Pytest Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Wed Jan 31 01:22:22 2018 From: flub at devork.be (Floris Bruynooghe) Date: Tue, 30 Jan 2018 22:22:22 -0800 Subject: [pytest-dev] Alias to parametrize In-Reply-To: <20180130085545.GX3489@beto> References: <20180130085545.GX3489@beto> Message-ID: 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(). 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 From variedthoughts at gmail.com Wed Jan 31 02:38:30 2018 From: variedthoughts at gmail.com (Brian Okken) Date: Tue, 30 Jan 2018 23:38:30 -0800 Subject: [pytest-dev] Alias to parametrize In-Reply-To: References: <20180130085545.GX3489@beto> Message-ID: 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 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(). > > 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 at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Wed Jan 31 04:42:52 2018 From: holger at merlinux.eu (holger krekel) Date: Wed, 31 Jan 2018 10:42:52 +0100 Subject: [pytest-dev] Alias to parametrize In-Reply-To: References: <20180130085545.GX3489@beto> Message-ID: <20180131094252.GJ3489@beto> 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