From nicoddemus at gmail.com  Tue Aug  1 18:40:32 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 01 Aug 2017 22:40:32 +0000
Subject: [pytest-dev] pytest 3.2.0 released
Message-ID: <CA+RQFffYdHOgr9gEFFDsL=TOyHMZFN1SanyRj0mRcEVdXRkMsw@mail.gmail.com>

The pytest team is proud to announce the 3.2.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 a number of bugs 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:

* Alex Hartoto
* Andras Tim
* Bruno Oliveira
* Daniel Hahler
* Florian Bruhin
* Floris Bruynooghe
* John Still
* Jordan Moldow
* Kale Kundert
* Lawrence Mitchell
* Llandy Riveron Del Risco
* Maik Figura
* Martin Altmayer
* Mihai Capot?
* Nathaniel Waisbrot
* Nguy?n H?ng Qu?n
* Pauli Virtanen
* Raphael Pierzina
* Ronny Pfannschmidt
* Segev Finer
* V.Kuznetsov


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

From opensource at ronnypfannschmidt.de  Sat Aug  5 03:37:17 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Sat, 5 Aug 2017 09:37:17 +0200
Subject: [pytest-dev] on opening up single character options via a registry
Message-ID: <9f430802-2921-f331-1a29-d0e4d90ff9e0@ronnypfannschmidt.de>

hi everyone,
as it pains me that we sneakily call private methods to use single
character options in xdist&co,
i propose to open up single character options to other plugins by means
of a registry,

so that plugins that have a registered single character will be able to
use it in py.test versions that have that association saved

we could even go as far as making the registry a extra pytest plugin
that can be updated out of band from pytest itself

-- Ronny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170805/7f38beb9/attachment.html>

From flub at devork.be  Sun Aug  6 16:11:39 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Sun, 06 Aug 2017 22:11:39 +0200
Subject: [pytest-dev] on opening up single character options via a
 registry
In-Reply-To: <9f430802-2921-f331-1a29-d0e4d90ff9e0@ronnypfannschmidt.de>
References: <9f430802-2921-f331-1a29-d0e4d90ff9e0@ronnypfannschmidt.de>
Message-ID: <87k22gmp6s.fsf@devork.be>

RonnyPfannschmidt <opensource at ronnypfannschmidt.de> writes:
> as it pains me that we sneakily call private methods to use single
> character options in xdist&co,
> i propose to open up single character options to other plugins by means
> of a registry,

What's wrong with the stance that this was a historical mistake and
should never have been allowed?  It's a lot easier to handle, i.e. do
nothing but apologise to plugin devs who want to use short options.

> so that plugins that have a registered single character will be able to
> use it in py.test versions that have that association saved
>
> we could even go as far as making the registry a extra pytest plugin
> that can be updated out of band from pytest itself

A plugin is probably the best way to go here.  It also means we'd be
exposing the register functionality via hooks which is cute as it allows
alternate registries to appear.  Your definition of cute may obviously
vary, but I think this would work out fine and no chaos would ensue.


Cheers,
Floris

From opensource at ronnypfannschmidt.de  Sun Aug  6 23:52:09 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Mon, 7 Aug 2017 05:52:09 +0200
Subject: [pytest-dev] on opening up single character options via a
 registry
In-Reply-To: <87k22gmp6s.fsf@devork.be>
References: <9f430802-2921-f331-1a29-d0e4d90ff9e0@ronnypfannschmidt.de>
 <87k22gmp6s.fsf@devork.be>
Message-ID: <942cc470-4285-33aa-bde5-b38259a7b7e2@ronnypfannschmidt.de>



Am 06.08.2017 um 22:11 schrieb Floris Bruynooghe:
> RonnyPfannschmidt <opensource at ronnypfannschmidt.de> writes:
>> as it pains me that we sneakily call private methods to use single
>> character options in xdist&co,
>> i propose to open up single character options to other plugins by means
>> of a registry,
> 
> What's wrong with the stance that this was a historical mistake and
> should never have been allowed?  It's a lot easier to handle, i.e. do
> nothing but apologise to plugin devs who want to use short options.

that is indeed an option,
i would prefer a way to have at least use the plugins under pytest-dev
use a well defined public specification in future

> 
>> so that plugins that have a registered single character will be able to
>> use it in py.test versions that have that association saved
>>
>> we could even go as far as making the registry a extra pytest plugin
>> that can be updated out of band from pytest itself
> 
> A plugin is probably the best way to go here.  It also means we'd be
> exposing the register functionality via hooks which is cute as it allows
> alternate registries to appear.  Your definition of cute may obviously
> vary, but I think this would work out fine and no chaos would ensue.
if we allow alternate registries for the pytest single character
options, then we just allow anyone to use anything after all.

collisions tend to be a pain, i believe its very helpful to have such a
registry as authoritative entity simply to avoid conflict for users

its already a pain to see the mess that's happening around marks and
mark name collisions, i don't see any compelling reason to repeat that
failure for options

-- Ronny

> >
> Cheers,
> Floris
> 

From daniele at vurt.org  Mon Aug  7 01:49:02 2017
From: daniele at vurt.org (Daniele Procida)
Date: Mon, 7 Aug 2017 15:49:02 +1000
Subject: [pytest-dev] Documentation proposal
In-Reply-To: <20170715103214.533927194@mail.gandi.net>
References: <20170715103214.533927194@mail.gandi.net>
Message-ID: <20170807054902.723005854@mail.gandi.net>

On Sat, Jul 15, 2017, Daniele Procida <daniele at vurt.org> wrote:

>I propose to restructure the pytest docmentation, according to this
>scheme <https://divio.com/blog/documentation> (the rationale for the
>scheme is described at length in that article).

Hi.

I have made a start on this since I first mentioned it at EuroPython.

You can see the work so far at <https://github.com/pytest-dev/pytest/compare/master...evildmp:documentation-restructure?expand=1>

To try it out locally:

Clone my branch and get into the right directory:

    git clone -b documentation-restructure git at github.com:evildmp/pytest.git
    cd pytest/doc/en

Set up the virtualenv for the docs:

    make install 

Start the documentation server:

    make run

Checkout the new documentation at <http://localhost:8001>.

Please note that there remains a lot more to do, but there is enough so far to get an idea of:

* how it will be structured
* what it will like

I have many questions, which are in issues on my fork: <https://github.com/evildmp/pytest/issues/>. 

Because commits land so fast in master (over 200 since I started working on this less than a month ago) it would be good to get some feedback on this and know whether this approach is going to be accepted into pytest. If so, I will be able to continue, with two main tasks:

* build Brianna's tutorial into the documentation
* work through every single page and ensure that all content is correctly placed in the appropriate section.

Thanks,

Daniele


From willingc at willingconsulting.com  Mon Aug  7 11:49:23 2017
From: willingc at willingconsulting.com (Carol Willing)
Date: Mon, 7 Aug 2017 08:49:23 -0700
Subject: [pytest-dev] Documentation proposal
In-Reply-To: <20170807054902.723005854@mail.gandi.net>
References: <20170715103214.533927194@mail.gandi.net>
 <20170807054902.723005854@mail.gandi.net>
Message-ID: <21F9994A-9319-4B4C-AC73-A4008369F4A8@willingconsulting.com>

Nice!

Just an FYI for those that use conda (and not virtualenv)... if you edit the Makefile html section and delete the portion of the line before sphinx-build then you can install the requirements.txt via pip, and build with make html.

Where do you want suggestions filed? I saw a few minor things such as Tutorial labeled as "Tutorial" in some places and "Introduction" in others. Breaking out the changelog to its own highlevel section would declutter the About section.

Thanks for doing this. We enjoy using pytest at Project Jupyter.

Carol

Carol Willing

Research Software Engineer
Project Jupyter at Cal Poly SLO

Signature Strengths
Empathy - Relator - Ideation - Strategic - Learner


> On Aug 6, 2017, at 10:49 PM, Daniele Procida <daniele at vurt.org> wrote:
> 
> On Sat, Jul 15, 2017, Daniele Procida <daniele at vurt.org> wrote:
> 
>> I propose to restructure the pytest docmentation, according to this
>> scheme <https://divio.com/blog/documentation> (the rationale for the
>> scheme is described at length in that article).
> 
> Hi,
> 
> I have made a start on this since I first mentioned it at EuroPython.
> 
> You can see the work so far at <https://github.com/pytest-dev/pytest/compare/master...evildmp:documentation-restructure?expand=1>
> 
> To try it out locally:
> 
> Clone my branch and get into the right directory:
> 
>    git clone -b documentation-restructure git at github.com:evildmp/pytest.git
>    cd pytest/doc/en
> 
> Set up the virtualenv for the docs:
> 
>    make install 
> 
> Start the documentation server:
> 
>    make run
> 
> Checkout the new documentation at <http://localhost:8001>.
> 
> Please note that there remains a lot more to do, but there is enough so far to get an idea of:
> 
> * how it will be structured
> * what it will like
> 
> I have many questions, which are in issues on my fork: <https://github.com/evildmp/pytest/issues/>. 
> 
> Because commits land so fast in master (over 200 since I started working on this less than a month ago) it would be good to get some feedback on this and know whether this approach is going to be accepted into pytest. If so, I will be able to continue, with two main tasks:
> 
> * build Brianna's tutorial into the documentation
> * work through every single page and ensure that all content is correctly placed in the appropriate section.
> 
> Thanks,
> 
> Daniele
> 
> _______________________________________________
> 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: <http://mail.python.org/pipermail/pytest-dev/attachments/20170807/8ad12a3c/attachment.html>

From nicoddemus at gmail.com  Mon Aug  7 12:07:15 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 07 Aug 2017 16:07:15 +0000
Subject: [pytest-dev] Documentation proposal
In-Reply-To: <20170807054902.723005854@mail.gandi.net>
References: <20170715103214.533927194@mail.gandi.net>
 <20170807054902.723005854@mail.gandi.net>
Message-ID: <CA+RQFfcr7LjedxLgax=wgOmdhOduavGUz1RooUFgXjbfR5Q6vw@mail.gmail.com>

Hi Daniele,

Thanks a lot for following up on this!

I've pushed your branch up to pytest's repository and enabled building it
on RTD so people can more easily take a look at it:

https://docs.pytest.org/en/documentation-restructure/

I did a quick glance and I like what I see so far. Having separate
tutorial/how-to guides/reference documents seems like a great improvement
because a common complain regarding pytest's docs was the fact that there
was no clear distinction between those different types of documentation.

>From my part I'm +1 on continue to work on this. :)

Cheers,
Bruno.


On Mon, Aug 7, 2017 at 2:50 AM Daniele Procida <daniele at vurt.org> wrote:

> On Sat, Jul 15, 2017, Daniele Procida <daniele at vurt.org> wrote:
>
> >I propose to restructure the pytest docmentation, according to this
> >scheme <https://divio.com/blog/documentation> (the rationale for the
> >scheme is described at length in that article).
>
> Hi.
>
> I have made a start on this since I first mentioned it at EuroPython.
>
> You can see the work so far at <
> https://github.com/pytest-dev/pytest/compare/master...evildmp:documentation-restructure?expand=1
> >
>
> To try it out locally:
>
> Clone my branch and get into the right directory:
>
>     git clone -b documentation-restructure git at github.com:
> evildmp/pytest.git
>     cd pytest/doc/en
>
> Set up the virtualenv for the docs:
>
>     make install
>
> Start the documentation server:
>
>     make run
>
> Checkout the new documentation at <http://localhost:8001>.
>
> Please note that there remains a lot more to do, but there is enough so
> far to get an idea of:
>
> * how it will be structured
> * what it will like
>
> I have many questions, which are in issues on my fork: <
> https://github.com/evildmp/pytest/issues/>.
>
> Because commits land so fast in master (over 200 since I started working
> on this less than a month ago) it would be good to get some feedback on
> this and know whether this approach is going to be accepted into pytest. If
> so, I will be able to continue, with two main tasks:
>
> * build Brianna's tutorial into the documentation
> * work through every single page and ensure that all content is correctly
> placed in the appropriate section.
>
> Thanks,
>
> Daniele
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/pytest-dev/attachments/20170807/816a2c2d/attachment.html>

From brianna.laugher at gmail.com  Mon Aug  7 18:44:30 2017
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Tue, 8 Aug 2017 08:44:30 +1000
Subject: [pytest-dev] Documentation proposal
In-Reply-To: <CA+RQFfcr7LjedxLgax=wgOmdhOduavGUz1RooUFgXjbfR5Q6vw@mail.gmail.com>
References: <20170715103214.533927194@mail.gandi.net>
 <20170807054902.723005854@mail.gandi.net>
 <CA+RQFfcr7LjedxLgax=wgOmdhOduavGUz1RooUFgXjbfR5Q6vw@mail.gmail.com>
Message-ID: <CAPjwCjsX9+jhRG0vk3Apy2NZRMkbGk59z6gzWBkoMd=B3rvNzA@mail.gmail.com>

Yes thanks Daniele!

Daniele gave a great talk at PyCon Australia this past weekend about these
four different types of documentation and how they are different/similar:
https://www.youtube.com/watch?v=t4vKPhjcMZg&list=PLs4CJRBY5F1KsK4AbFaPsUT8X8iXc7X84&index=65

Daniele referred to "Brianna's tutorial", which is the materials for a 3
hour tutorial that I gave at the conference. It doesn't have video, but the
materials are here:

https://www.dropbox.com/sh/jx44jys7g6v5gy8/AAB49nqGd4_FXUqq6SjN4V6wa?dl=0

The concept of the tutorial was to use a "starter" application and test
suite and build on/modify that. The application is
https://github.com/pfctdayelise/allseasons

I have a lot of notes and feedback from giving the tutorial itself to feed
back to the pytest community (mainly around using pytest-bdd/splinter/Xvfb
on Windows and OSX), but I am still in recovery mode from the conference
itself so it will take me a little longer to write that up.

cheers
Brianna


On 8 August 2017 at 02:07, Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi Daniele,
>
> Thanks a lot for following up on this!
>
> I've pushed your branch up to pytest's repository and enabled building it
> on RTD so people can more easily take a look at it:
>
> https://docs.pytest.org/en/documentation-restructure/
>
> I did a quick glance and I like what I see so far. Having separate
> tutorial/how-to guides/reference documents seems like a great improvement
> because a common complain regarding pytest's docs was the fact that there
> was no clear distinction between those different types of documentation.
>
> From my part I'm +1 on continue to work on this. :)
>
> Cheers,
> Bruno.
>
>
> On Mon, Aug 7, 2017 at 2:50 AM Daniele Procida <daniele at vurt.org> wrote:
>
>> On Sat, Jul 15, 2017, Daniele Procida <daniele at vurt.org> wrote:
>>
>> >I propose to restructure the pytest docmentation, according to this
>> >scheme <https://divio.com/blog/documentation> (the rationale for the
>> >scheme is described at length in that article).
>>
>> Hi.
>>
>> I have made a start on this since I first mentioned it at EuroPython.
>>
>> You can see the work so far at <https://github.com/pytest-
>> dev/pytest/compare/master...evildmp:documentation-restructure?expand=1>
>>
>> To try it out locally:
>>
>> Clone my branch and get into the right directory:
>>
>>     git clone -b documentation-restructure git at github.com:evildmp/pytest.
>> git
>>     cd pytest/doc/en
>>
>> Set up the virtualenv for the docs:
>>
>>     make install
>>
>> Start the documentation server:
>>
>>     make run
>>
>> Checkout the new documentation at <http://localhost:8001>.
>>
>> Please note that there remains a lot more to do, but there is enough so
>> far to get an idea of:
>>
>> * how it will be structured
>> * what it will like
>>
>> I have many questions, which are in issues on my fork: <
>> https://github.com/evildmp/pytest/issues/>.
>>
>> Because commits land so fast in master (over 200 since I started working
>> on this less than a month ago) it would be good to get some feedback on
>> this and know whether this approach is going to be accepted into pytest. If
>> so, I will be able to continue, with two main tasks:
>>
>> * build Brianna's tutorial into the documentation
>> * work through every single page and ensure that all content is correctly
>> placed in the appropriate section.
>>
>> Thanks,
>>
>> Daniele
>>
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170808/243eace6/attachment.html>

From opensource at ronnypfannschmidt.de  Wed Aug  9 09:18:25 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Wed, 9 Aug 2017 15:18:25 +0200
Subject: [pytest-dev] plan change for marks - earlier introduction of the
 inheritance compatible apis
Message-ID: <edeae700-2fb5-851b-0c5f-ec93e4e239eb@ronnypfannschmidt.de>

Hi everyone,

after trying for a while to sanely introduce a FunctionDefinition node type,
and failing due to pretty nasty coupling in the code,

i decided i will introduce inheritance compatible marker apis in a
different way

this will mean a slight mess due to the lack of some important correct
places for marks,
but it will allow to finally use marks correctly at least

the main problem point will be the transfer of marks from call
specs/parameterized calls
to normal functions

as usually when the legacy mark api are involved, type and structure of
the involved data is not just wrong but inherently hostile to reliable
programming.

so even when going for a less sensible structure to get it trough in a
smaller package i expect some horrendous fallout.

-- Ronny




From nicoddemus at gmail.com  Wed Aug  9 16:17:34 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 09 Aug 2017 20:17:34 +0000
Subject: [pytest-dev] pytest 3.2.1 released
Message-ID: <CA+RQFfe_oCZQgKz_t7Btg30_--zz1pfkvaL_2qLyyh9NtNt24A@mail.gmail.com>

pytest 3.2.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:

* Alex Gaynor
* Bruno Oliveira
* Florian Bruhin
* Ronny Pfannschmidt
* Srinivas Reddy Thatiparthy


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

From nicoddemus at gmail.com  Fri Aug 11 09:22:09 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 11 Aug 2017 13:22:09 +0000
Subject: [pytest-dev] Documentation proposal
In-Reply-To: <CAPjwCjsX9+jhRG0vk3Apy2NZRMkbGk59z6gzWBkoMd=B3rvNzA@mail.gmail.com>
References: <20170715103214.533927194@mail.gandi.net>
 <20170807054902.723005854@mail.gandi.net>
 <CA+RQFfcr7LjedxLgax=wgOmdhOduavGUz1RooUFgXjbfR5Q6vw@mail.gmail.com>
 <CAPjwCjsX9+jhRG0vk3Apy2NZRMkbGk59z6gzWBkoMd=B3rvNzA@mail.gmail.com>
Message-ID: <CA+RQFfd1ypcGFZ1M6gJP7GQMT5pKUDfxR9yLX9F_hrONyJDTog@mail.gmail.com>

Daniele,

I think nobody is against this refactoring, so please go ahead and let us
know of the progress. I sent you an invite as a collaborator of the pytest
repository so I think you can continue your work by pushing your changes
directly to the pytest-dev/pytest at documentation-restructure branch. This
will automatically rebuild the documentation which we can use for easier
reviewing it.

Raphael and Brianna,

What should we do with the reorganize-docs branch that was created during
the sprint?

Cheers,
Bruno.


On Mon, Aug 7, 2017 at 7:44 PM Brianna Laugher <brianna.laugher at gmail.com>
wrote:

> Yes thanks Daniele!
>
> Daniele gave a great talk at PyCon Australia this past weekend about these
> four different types of documentation and how they are different/similar:
> https://www.youtube.com/watch?v=t4vKPhjcMZg&list=PLs4CJRBY5F1KsK4AbFaPsUT8X8iXc7X84&index=65
>
> Daniele referred to "Brianna's tutorial", which is the materials for a 3
> hour tutorial that I gave at the conference. It doesn't have video, but the
> materials are here:
>
> https://www.dropbox.com/sh/jx44jys7g6v5gy8/AAB49nqGd4_FXUqq6SjN4V6wa?dl=0
>
> The concept of the tutorial was to use a "starter" application and test
> suite and build on/modify that. The application is
> https://github.com/pfctdayelise/allseasons
>
> I have a lot of notes and feedback from giving the tutorial itself to feed
> back to the pytest community (mainly around using pytest-bdd/splinter/Xvfb
> on Windows and OSX), but I am still in recovery mode from the conference
> itself so it will take me a little longer to write that up.
>
> cheers
> Brianna
>
>
> On 8 August 2017 at 02:07, Bruno Oliveira <nicoddemus at gmail.com> wrote:
>
>> Hi Daniele,
>>
>> Thanks a lot for following up on this!
>>
>> I've pushed your branch up to pytest's repository and enabled building it
>> on RTD so people can more easily take a look at it:
>>
>> https://docs.pytest.org/en/documentation-restructure/
>>
>> I did a quick glance and I like what I see so far. Having separate
>> tutorial/how-to guides/reference documents seems like a great improvement
>> because a common complain regarding pytest's docs was the fact that there
>> was no clear distinction between those different types of documentation.
>>
>> From my part I'm +1 on continue to work on this. :)
>>
>> Cheers,
>> Bruno.
>>
>>
>> On Mon, Aug 7, 2017 at 2:50 AM Daniele Procida <daniele at vurt.org> wrote:
>>
>>> On Sat, Jul 15, 2017, Daniele Procida <daniele at vurt.org> wrote:
>>>
>>> >I propose to restructure the pytest docmentation, according to this
>>> >scheme <https://divio.com/blog/documentation> (the rationale for the
>>> >scheme is described at length in that article).
>>>
>>> Hi.
>>>
>>> I have made a start on this since I first mentioned it at EuroPython.
>>>
>>> You can see the work so far at <
>>> https://github.com/pytest-dev/pytest/compare/master...evildmp:documentation-restructure?expand=1
>>> >
>>>
>>> To try it out locally:
>>>
>>> Clone my branch and get into the right directory:
>>>
>>>     git clone -b documentation-restructure git at github.com:
>>> evildmp/pytest.git
>>>     cd pytest/doc/en
>>>
>>> Set up the virtualenv for the docs:
>>>
>>>     make install
>>>
>>> Start the documentation server:
>>>
>>>     make run
>>>
>>> Checkout the new documentation at <http://localhost:8001>.
>>>
>>> Please note that there remains a lot more to do, but there is enough so
>>> far to get an idea of:
>>>
>>> * how it will be structured
>>> * what it will like
>>>
>>> I have many questions, which are in issues on my fork: <
>>> https://github.com/evildmp/pytest/issues/>.
>>>
>>> Because commits land so fast in master (over 200 since I started working
>>> on this less than a month ago) it would be good to get some feedback on
>>> this and know whether this approach is going to be accepted into pytest. If
>>> so, I will be able to continue, with two main tasks:
>>>
>>> * build Brianna's tutorial into the documentation
>>> * work through every single page and ensure that all content is
>>> correctly placed in the appropriate section.
>>>
>>> Thanks,
>>>
>>> Daniele
>>>
>>> _______________________________________________
>>> pytest-dev mailing list
>>> pytest-dev at python.org
>>> https://mail.python.org/mailman/listinfo/pytest-dev
>>>
>>
>> _______________________________________________
>> pytest-dev mailing list
>> pytest-dev at python.org
>> https://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
>
>
> --
> They've just been waiting in a mountain for the right moment:
> http://modernthings.org/
> _______________________________________________
> 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: <http://mail.python.org/pipermail/pytest-dev/attachments/20170811/71731aa1/attachment.html>

From opensource at ronnypfannschmidt.de  Fri Aug 18 08:24:57 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Fri, 18 Aug 2017 14:24:57 +0200
Subject: [pytest-dev] hangout for mark api brainstorming - i made a doodle
 with options
Message-ID: <3cf78523-3b6e-2083-f773-8c218d658e62@ronnypfannschmidt.de>

HI everyone,

as i'm now hitting a place where i need to create the next gen api for
interacting with marks,
i believe a brainstorming is needed in order to get some diversity in
ideas upfront.

i made a doodle for the options at
https://beta.doodle.com/poll/nhqinh6ckzhryt58#link

over the course of the weekend i#ll prepare a bit more details on my
thoughts so we can start at a reasonable base.

-- Ronny


From opensource at ronnypfannschmidt.de  Thu Aug 24 13:55:30 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Thu, 24 Aug 2017 19:55:30 +0200
Subject: [pytest-dev] hangout for mark api brainstorming - canceling
 alltogether
In-Reply-To: <3cf78523-3b6e-2083-f773-8c218d658e62@ronnypfannschmidt.de>
References: <3cf78523-3b6e-2083-f773-8c218d658e62@ronnypfannschmidt.de>
Message-ID: <e9a832b6-8982-7935-444b-97cab0529cc9@ronnypfannschmidt.de>

Hi everyone,

for family reasons (a baby is always up for surprises)
i cant really make it to a call anyway

i will start creating smaller focussed discussions on the ml instead

-- Ronny


On 18.08.2017 14:24, RonnyPfannschmidt wrote:
> HI everyone,
> 
> as i'm now hitting a place where i need to create the next gen api for
> interacting with marks,
> i believe a brainstorming is needed in order to get some diversity in
> ideas upfront.
> 
> i made a doodle for the options at
> https://beta.doodle.com/poll/nhqinh6ckzhryt58#link
> 
> over the course of the weekend i#ll prepare a bit more details on my
> thoughts so we can start at a reasonable base.
> 
> -- Ronny
> 
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
> 

From nicoddemus at gmail.com  Thu Aug 24 13:57:14 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 24 Aug 2017 17:57:14 +0000
Subject: [pytest-dev] hangout for mark api brainstorming - canceling
 alltogether
In-Reply-To: <e9a832b6-8982-7935-444b-97cab0529cc9@ronnypfannschmidt.de>
References: <3cf78523-3b6e-2083-f773-8c218d658e62@ronnypfannschmidt.de>
 <e9a832b6-8982-7935-444b-97cab0529cc9@ronnypfannschmidt.de>
Message-ID: <CA+RQFfeTLWsH-fUQm5kxdBmwbXMEpKsxY=qgrLaes=9T5sG0ig@mail.gmail.com>

OK Ronny, thanks!

On Thu, Aug 24, 2017 at 2:55 PM RonnyPfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi everyone,
>
> for family reasons (a baby is always up for surprises)
> i cant really make it to a call anyway
>
> i will start creating smaller focussed discussions on the ml instead
>
> -- Ronny
>
>
> On 18.08.2017 14:24, RonnyPfannschmidt wrote:
> > HI everyone,
> >
> > as i'm now hitting a place where i need to create the next gen api for
> > interacting with marks,
> > i believe a brainstorming is needed in order to get some diversity in
> > ideas upfront.
> >
> > i made a doodle for the options at
> > https://beta.doodle.com/poll/nhqinh6ckzhryt58#link
> >
> > over the course of the weekend i#ll prepare a bit more details on my
> > thoughts so we can start at a reasonable base.
> >
> > -- Ronny
> >
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >
> _______________________________________________
> 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: <http://mail.python.org/pipermail/pytest-dev/attachments/20170824/90b2237c/attachment.html>

From opensource at ronnypfannschmidt.de  Fri Aug 25 10:13:16 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Fri, 25 Aug 2017 16:13:16 +0200
Subject: [pytest-dev] marks - proposals for a new api and a path forward
Message-ID: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>

Hi everyone,

as far as i am concerned, we cant hope to safe the current mark api,

Node.get_marker is just a hack looking into keywords (which is a legacy
half broken concept and the base of marks on nodes and why they are so
broken

Node.add_markers is just plain wrong, and by plain wrong i mean totally
plain wrong


so in order to move forward, i'd like to leave all those messy pieces in
place and just deprecate them, so we can remove them much later


going forward i'd like to introduce 2 things to nodes

1. a list of their *own* markers, as a subtype of list ensuring mark
decroators are correctly unpacked, that list would be the new per-node api

2. a function to iterate all marks of a node and its parents, optionally
filtered by name,

yielding tuples of (mark, node)


once that is done almost all incorrect mark usages can be fixed
relatively sanely

afterwards going forward i'd like to introduce class based marks,
where instead of using a string and random data, we get to use instances
of clearly defined classes as markers,

going for class based markers has various massive advantages

a) ability to use inheritance when searching
b) name-spacing is solved by python itself

-- Ronny

From variedthoughts at gmail.com  Sat Aug 26 12:36:15 2017
From: variedthoughts at gmail.com (Brian Okken)
Date: Sat, 26 Aug 2017 09:36:15 -0700
Subject: [pytest-dev] Dir names that aren't valid module names.
Message-ID: <EE6CBD67-95E0-421B-8DF3-332B552CADBF@gmail.com>

	Matt Craig (@astronomatty)
8/25/17, 2:15 PM
"Fun" fact: pytest fails with an obscure error if a dir name has dashes in it. pic.twitter.com/3JGzWBcqqO

Not sure if this is a reported issue or even real. But I saw it on twitter and thought I'd pass it along. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170826/44d7621b/attachment.html>

From variedthoughts at gmail.com  Sat Aug 26 12:30:07 2017
From: variedthoughts at gmail.com (Brian Okken)
Date: Sat, 26 Aug 2017 09:30:07 -0700
Subject: [pytest-dev] marks - proposals for a new api and a path forward
In-Reply-To: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
References: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
Message-ID: <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>

I'd personally like to see an example to show the new API proposal. How would it look to a user? How would it look to a plugin dev?

- Brian 

Sent from my iPhone

> On Aug 25, 2017, at 7:13 AM, RonnyPfannschmidt <opensource at ronnypfannschmidt.de> wrote:
> 
> Hi everyone,
> 
> as far as i am concerned, we cant hope to safe the current mark api,
> 
> Node.get_marker is just a hack looking into keywords (which is a legacy
> half broken concept and the base of marks on nodes and why they are so
> broken
> 
> Node.add_markers is just plain wrong, and by plain wrong i mean totally
> plain wrong
> 
> 
> so in order to move forward, i'd like to leave all those messy pieces in
> place and just deprecate them, so we can remove them much later
> 
> 
> going forward i'd like to introduce 2 things to nodes
> 
> 1. a list of their *own* markers, as a subtype of list ensuring mark
> decroators are correctly unpacked, that list would be the new per-node api
> 
> 2. a function to iterate all marks of a node and its parents, optionally
> filtered by name,
> 
> yielding tuples of (mark, node)
> 
> 
> once that is done almost all incorrect mark usages can be fixed
> relatively sanely
> 
> afterwards going forward i'd like to introduce class based marks,
> where instead of using a string and random data, we get to use instances
> of clearly defined classes as markers,
> 
> going for class based markers has various massive advantages
> 
> a) ability to use inheritance when searching
> b) name-spacing is solved by python itself
> 
> -- Ronny
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From opensource at ronnypfannschmidt.de  Sun Aug 27 03:02:48 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Sun, 27 Aug 2017 09:02:48 +0200
Subject: [pytest-dev] marks - proposals for a new api and a path forward
In-Reply-To: <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>
References: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
 <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>
Message-ID: <1503817368.21878.15.camel@ronnypfannschmidt.de>

Hi Brian,

good call, i should extend this writing to it makes sens


what i imagine is an api like this:

node.find_marks() -> iterates over all marks of all nodes
node.find_marks('name') -> iterates over all marks that have a name
node.find_marks(SomeType) -> iterates over all marks that are instaces
of the type


node.find_marks_with_nodes(...) same as find_marks, however iterate
over tuples of (node, mark) where nodeis the owning node and mark is
the mark object.


node.push_mark(markobj) -> pushes a mark to a node, always requires a
mark object wither taken from pytest.mark or a new style one

following up the evaluation of skip marksfor example would look like
this:

for mark in node.find_marks('skip'):
   if eval_mark(node, mark):
      pytest.skip(mark.args)


a more complex marker could be wored the following


for orgin, blocker in node.find_marks_with_node(Blocker):
   blocker.maybe_trigger_outcome(orgin=orgin, current=node)
      


as for putting those marks on nodes,
i would just use pytest.mark(Foo(a=1. b=2) as the deorator

cheers, Ronny

Am Samstag, den 26.08.2017, 09:30 -0700 schrieb Brian Okken:
> I'd personally like to see an example to show the new API proposal.
> How would it look to a user? How would it look to a plugin dev?
> 
> - Brian 
> 
> Sent from my iPhone
> 
> > On Aug 25, 2017, at 7:13 AM, RonnyPfannschmidt <opensource at ronnypfa
> > nnschmidt.de> wrote:
> > 
> > Hi everyone,
> > 
> > as far as i am concerned, we cant hope to safe the current mark
> > api,
> > 
> > Node.get_marker is just a hack looking into keywords (which is a
> > legacy
> > half broken concept and the base of marks on nodes and why they are
> > so
> > broken
> > 
> > Node.add_markers is just plain wrong, and by plain wrong i mean
> > totally
> > plain wrong
> > 
> > 
> > so in order to move forward, i'd like to leave all those messy
> > pieces in
> > place and just deprecate them, so we can remove them much later
> > 
> > 
> > going forward i'd like to introduce 2 things to nodes
> > 
> > 1. a list of their *own* markers, as a subtype of list ensuring
> > mark
> > decroators are correctly unpacked, that list would be the new per-
> > node api
> > 
> > 2. a function to iterate all marks of a node and its parents,
> > optionally
> > filtered by name,
> > 
> > yielding tuples of (mark, node)
> > 
> > 
> > once that is done almost all incorrect mark usages can be fixed
> > relatively sanely
> > 
> > afterwards going forward i'd like to introduce class based marks,
> > where instead of using a string and random data, we get to use
> > instances
> > of clearly defined classes as markers,
> > 
> > going for class based markers has various massive advantages
> > 
> > a) ability to use inheritance when searching
> > b) name-spacing is solved by python itself
> > 
> > -- Ronny
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev

From opensource at ronnypfannschmidt.de  Tue Aug 29 03:48:25 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Tue, 29 Aug 2017 09:48:25 +0200
Subject: [pytest-dev] [proposal] deprecate magic constant scopes in favour
 of the node types
Message-ID: <ac5d4800-3bc4-c4ad-4725-bed8e9e53bcb@ronnypfannschmidt.de>

Hi all,

since quite a while now we have used magic constants for scope names,
while we have something perfectly fitting already at hand - namely the
Node classes we actually use and mean

i believe its a disservice that we use magic strings one has to manually
map while we have very exact names for those already

-- Ronny


From nicoddemus at gmail.com  Tue Aug 29 09:18:02 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 29 Aug 2017 13:18:02 +0000
Subject: [pytest-dev] marks - proposals for a new api and a path forward
In-Reply-To: <1503817368.21878.15.camel@ronnypfannschmidt.de>
References: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
 <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>
 <1503817368.21878.15.camel@ronnypfannschmidt.de>
Message-ID: <CA+RQFfebaN20rXyX0en=dEb=FZ9zXif3AUQm8RiuWRvTZFWChQ@mail.gmail.com>

Hi guys,

Sorry for not answering earlier.

On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi Brian,
>
> good call, i should extend this writing to it makes sens
>
>
> what i imagine is an api like this:
>
> node.find_marks() -> iterates over all marks of all nodes
> node.find_marks('name') -> iterates over all marks that have a name
> node.find_marks(SomeType) -> iterates over all marks that are instaces
> of the type
>

This seems reasonable. Minor suggestion, perhaps name the methods
"iter_marks" instead? Seems better based on the descriptions of each one
("iterates over all marks...")

What about the existing `Node.get_mark` method? I suppose it could still be
supported and always returns the first marker it finds.

node.find_marks_with_nodes(...) same as find_marks, however iterate
> over tuples of (node, mark) where nodeis the owning node and mark is
> the mark object.
>

node is the node object or node id? Following my previous suggestion this
might be also called "node.iter_marks_and_nodes".



> node.push_mark(markobj) -> pushes a mark to a node, always requires a
> mark object wither taken from pytest.mark or a new style one
>
> following up the evaluation of skip marksfor example would look like
> this:
>
> for mark in node.find_marks('skip'):
>    if eval_mark(node, mark):
>       pytest.skip(mark.args)
>
>
> a more complex marker could be wored the following
>
>
> for orgin, blocker in node.find_marks_with_node(Blocker):
>    blocker.maybe_trigger_outcome(orgin=orgin, current=node)
>
>
>
> as for putting those marks on nodes,
> i would just use pytest.mark(Foo(a=1. b=2) as the deorator
>

I definitely like this idea, this will handle *args and **kwargs much more
naturally and less error prone, plus it makes it easier to document marks
as well.

Overall I like the direction this is going. What about the classic marks? I
would like it very much to keep them around as they are, instead of
deprecating them. As you showed above, they can co-exist just fine.

Thanks again for tackling this Ronny!

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

From nicoddemus at gmail.com  Tue Aug 29 09:19:50 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 29 Aug 2017 13:19:50 +0000
Subject: [pytest-dev] [proposal] deprecate magic constant scopes in
 favour of the node types
In-Reply-To: <ac5d4800-3bc4-c4ad-4725-bed8e9e53bcb@ronnypfannschmidt.de>
References: <ac5d4800-3bc4-c4ad-4725-bed8e9e53bcb@ronnypfannschmidt.de>
Message-ID: <CA+RQFfd4yMVM+bSUofbWx7oQhpPLnJoRzz3+NzkHek9+F7oMUg@mail.gmail.com>

Hi Ronny,

On Tue, Aug 29, 2017 at 4:48 AM RonnyPfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi all,
>
> since quite a while now we have used magic constants for scope names,
> while we have something perfectly fitting already at hand - namely the
> Node classes we actually use and mean
>
> i believe its a disservice that we use magic strings one has to manually
> map while we have very exact names for those already
>

I like the idea in general of using specific constants instead of magic
strings, but in this specific case we also have to take in account the
problem of asking all users to change the API for very little gain in terms
of internal code: just a few lines of trivial code which maps the strings.
Also keep in mind that we will have to support the magic constants anyway
for years to come, so the (small) code advantage won't happen for quite a
long time, we will only add more cognitive burden to users to have two ways
of doing the same thing.

In summary I'm all for improving the API and the internal code if this will
bring us strong gains, I just don't think this is one of those cases so I'm
-1 on the idea.

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

From opensource at ronnypfannschmidt.de  Tue Aug 29 09:43:09 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Tue, 29 Aug 2017 15:43:09 +0200
Subject: [pytest-dev] marks - proposals for a new api and a path forward
In-Reply-To: <CA+RQFfebaN20rXyX0en=dEb=FZ9zXif3AUQm8RiuWRvTZFWChQ@mail.gmail.com>
References: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
 <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>
 <1503817368.21878.15.camel@ronnypfannschmidt.de>
 <CA+RQFfebaN20rXyX0en=dEb=FZ9zXif3AUQm8RiuWRvTZFWChQ@mail.gmail.com>
Message-ID: <63b2232b-96f7-2402-f98d-c08dfaf23973@ronnypfannschmidt.de>

Hola Bruno,



Am 29.08.2017 um 15:18 schrieb Bruno Oliveira:
> Hi guys,
> 
> Sorry for not answering earlier.
> 
> On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt
> <opensource at ronnypfannschmidt.de
> <mailto:opensource at ronnypfannschmidt.de>> wrote:
> 
>     Hi Brian,
> 
>     good call, i should extend this writing to it makes sens
> 
> 
>     what i imagine is an api like this:
> 
>     node.find_marks() -> iterates over all marks of all nodes
>     node.find_marks('name') -> iterates over all marks that have a name
>     node.find_marks(SomeType) -> iterates over all marks that are instaces
>     of the type
> 
> 
> This seems reasonable. Minor suggestion, perhaps name the methods
> "iter_marks" instead? Seems better based on the descriptions of each one
> ("iterates over all marks...")

i'd like to bikeshed on the names a bit in order to give them exactly
the meaning they should have - perhaps i should split iteration and
filtering even

> 
> What about the existing `Node.get_mark` method? I suppose it could still
> be supported and always returns the first marker it finds. 
the existing method has pretty much erratic behavior that cant be fixed
without breaking api

also only going for the first mark is practically always wrong - its
much better spelled using the next builtin so the intent/behavior is clear


> 
>     node.find_marks_with_nodes(...) same as find_marks, however iterate
>     over tuples of (node, mark) where nodeis the owning node and mark is
>     the mark object.
> 
> 
> node is the node object or node id? Following my previous suggestion
> this might be also called "node.iter_marks_and_nodes".
yup
> 
>  
> 
>     node.push_mark(markobj) -> pushes a mark to a node, always requires a
>     mark object wither taken from pytest.mark or a new style one
> 
>     following up the evaluation of skip marksfor example would look like
>     this:
> 
>     for mark in node.find_marks('skip'):
>        if eval_mark(node, mark):
>           pytest.skip(mark.args)
> 
> 
>     a more complex marker could be wored the following
> 
> 
>     for orgin, blocker in node.find_marks_with_node(Blocker):
>        blocker.maybe_trigger_outcome(orgin=orgin, current=node)
> 
> 
> 
>     as for putting those marks on nodes,
>     i would just use pytest.mark(Foo(a=1. b=2) as the deorator
> 
> 
> I definitely like this idea, this will handle *args and **kwargs much
> more naturally and less error prone, plus it makes it easier to document
> marks as well.
> 
> Overall I like the direction this is going. What about the classic
> marks? I would like it very much to keep them around as they are,
> instead of deprecating them. As you showed above, they can co-exist just
> fine.

i don't plan on deprecating the old marks,
but it may be a good idea to deprecate 3rd party pytest plugins having
own marks in the future (doing it now would be too big of a pain for users)



-- Ronny

> 
> Thanks again for tackling this Ronny!
> 
> Cheers,
> Bruno.

From opensource at ronnypfannschmidt.de  Tue Aug 29 09:47:19 2017
From: opensource at ronnypfannschmidt.de (RonnyPfannschmidt)
Date: Tue, 29 Aug 2017 15:47:19 +0200
Subject: [pytest-dev] [proposal] deprecate magic constant scopes in
 favour of the node types
In-Reply-To: <CA+RQFfd4yMVM+bSUofbWx7oQhpPLnJoRzz3+NzkHek9+F7oMUg@mail.gmail.com>
References: <ac5d4800-3bc4-c4ad-4725-bed8e9e53bcb@ronnypfannschmidt.de>
 <CA+RQFfd4yMVM+bSUofbWx7oQhpPLnJoRzz3+NzkHek9+F7oMUg@mail.gmail.com>
Message-ID: <ac9ecb3e-217a-2d5d-67a9-36d2f671c874@ronnypfannschmidt.de>



Am 29.08.2017 um 15:19 schrieb Bruno Oliveira:
> Hi Ronny,
> 
> On Tue, Aug 29, 2017 at 4:48 AM RonnyPfannschmidt
> <opensource at ronnypfannschmidt.de
> <mailto:opensource at ronnypfannschmidt.de>> wrote:
> 
>     Hi all,
> 
>     since quite a while now we have used magic constants for scope names,
>     while we have something perfectly fitting already at hand - namely the
>     Node classes we actually use and mean
> 
>     i believe its a disservice that we use magic strings one has to manually
>     map while we have very exact names for those already
> 
> 
> I like the idea in general of using specific constants instead of magic
> strings, but in this specific case we also have to take in account the
> problem of asking all users to change the API for very little gain in
> terms of internal code: just a few lines of trivial code which maps the
> strings. Also keep in mind that we will have to support the magic
> constants anyway for years to come, so the (small) code advantage won't
> happen for quite a long time, we will only add more cognitive burden to
> users to have two ways of doing the same thing.
> 
> In summary I'm all for improving the API and the internal code if this
> will bring us strong gains, I just don't think this is one of those
> cases so I'm -1 on the idea.
> 

as a starting point i'd like to be able to use objects to declare the
scope instead of strings

because in future we plan to have per request scopes, and multi scopes
as well, and at that point its not just a bunch of strings, but a bunch
of increasingly magical messy strings - so its not going to stay a
simple mapping

so i'd prefer to open the path to sanity before things get worse,
because in pytest we have a history of bad things getting worse
(see marks, collection tree, scoping of setup functions)


-- Ronny

> Cheers,
> Bruno. 

From flub at devork.be  Tue Aug 29 14:51:42 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 29 Aug 2017 20:51:42 +0200
Subject: [pytest-dev] [proposal] deprecate magic constant scopes in
 favour of the node types
In-Reply-To: <ac5d4800-3bc4-c4ad-4725-bed8e9e53bcb@ronnypfannschmidt.de>
References: <ac5d4800-3bc4-c4ad-4725-bed8e9e53bcb@ronnypfannschmidt.de>
Message-ID: <87y3q2us01.fsf@devork.be>

RonnyPfannschmidt <opensource at ronnypfannschmidt.de> writes:
> since quite a while now we have used magic constants for scope names,

Are you talking about the "module" string in ``@pytest.fixture(scope='module')``?

> while we have something perfectly fitting already at hand - namely the
> Node classes we actually use and mean

So are you suggesting ``@pytest.fixture(scope=pytest.Module)`` instead?

> i believe its a disservice that we use magic strings one has to manually
> map while we have very exact names for those already

If the above is what you're suggesting I can't imagine users to be very
happy about this.  To be honest even pytest.Module seems pretty ad-hoc
to me.  If there is a good reason to have something which is not a
string at some point there's no harm into accepting both, they're still
unique objects.  I just don't currently understand why this might be
needed or desirable.

From flub at devork.be  Tue Aug 29 15:53:17 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 29 Aug 2017 21:53:17 +0200
Subject: [pytest-dev] marks - proposals for a new api and a path forward
In-Reply-To: <63b2232b-96f7-2402-f98d-c08dfaf23973@ronnypfannschmidt.de>
References: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
 <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>
 <1503817368.21878.15.camel@ronnypfannschmidt.de>
 <CA+RQFfebaN20rXyX0en=dEb=FZ9zXif3AUQm8RiuWRvTZFWChQ@mail.gmail.com>
 <63b2232b-96f7-2402-f98d-c08dfaf23973@ronnypfannschmidt.de>
Message-ID: <87shgaup5e.fsf@devork.be>

Hello,

RonnyPfannschmidt <opensource at ronnypfannschmidt.de> writes:
> Am 29.08.2017 um 15:18 schrieb Bruno Oliveira:
>> On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt
>> <opensource at ronnypfannschmidt.de
>> <mailto:opensource at ronnypfannschmidt.de>> wrote:
>>     what i imagine is an api like this:
>> 
>>     node.find_marks() -> iterates over all marks of all nodes
>>     node.find_marks('name') -> iterates over all marks that have a name
>>     node.find_marks(SomeType) -> iterates over all marks that are instaces
>>     of the type
>> 
>> 
>> This seems reasonable. Minor suggestion, perhaps name the methods
>> "iter_marks" instead? Seems better based on the descriptions of each one
>> ("iterates over all marks...")
>
> i'd like to bikeshed on the names a bit in order to give them exactly
> the meaning they should have - perhaps i should split iteration and
> filtering even

In general I'd agree that splitting the iteration and filtering might be
more pythonic, also python has generally moved away from calling things
"iter_*" I think.  Lastly I find the Node.find_marks_with_nodes()
variation rather clumsy as well.

After thinking about this a bit the best I can come up with is the
simple Node.marks() method.  As is common in Python it takes no
arguments and does not filter, it just returns an iterator.  To make
that work you'd also need to change what object the iterator returns, I
imagine something like this:

class MarkHolder:
    name = 'old_mark_name' or None
    obj = SomeType or whatever obj the old ones are
    origin = Node

(As an aside I'm guessing this class would be a prime candidate to be
marked @attr.s thing)

While you get an extra layer it's both rather Pythonic in the API with
respect to the behaviour of the iterator method as well as py.testy with
the use of holder.obj.  (I'm not sure if "py.testy" is generally
perceived as a desirable property or not ;-))


>>     node.push_mark(markobj) -> pushes a mark to a node, always requires a
>>     mark object wither taken from pytest.mark or a new style one

This method I do like, it should probably come with a symmetric
Node.pop_mark() as well which would mirror dict.pop() behaviour.


>>     following up the evaluation of skip marksfor example would look like
>>     this:
>> 
>>     for mark in node.find_marks('skip'):
>>        if eval_mark(node, mark):
>>           pytest.skip(mark.args)

for mark in (m for m in node.marks() if m.name == 'skip'):
    ...

>>     a more complex marker could be wored the following
>> 
>>     for orgin, blocker in node.find_marks_with_node(Blocker):
>>        blocker.maybe_trigger_outcome(orgin=orgin, current=node)

for mark in (m for m in node.marks() if isinstance(m.obj, Blocker)):
    mark.obj.maybe_trigger_outcome(origin=mark.origin, current=node)

Having written these examples without any filtering API I do admit I'm
doubting my earlier evaluation about this being a more Pythonic API.  It
certainly is a lot more writing and probably even harder to read as
well.  But I thought I'd still send the mail as it's still useful food
for thought.

>>     as for putting those marks on nodes,
>>     i would just use pytest.mark(Foo(a=1. b=2) as the deorator
>> 
>> 
>> I definitely like this idea, this will handle *args and **kwargs much
>> more naturally and less error prone, plus it makes it easier to document
>> marks as well.

Agreed that this seems nice.


Cheers,
Floris

From nicoddemus at gmail.com  Tue Aug 29 18:56:22 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 29 Aug 2017 22:56:22 +0000
Subject: [pytest-dev] marks - proposals for a new api and a path forward
In-Reply-To: <87shgaup5e.fsf@devork.be>
References: <4d907183-518c-1941-cdfa-e002314377b2@ronnypfannschmidt.de>
 <7ECD795D-2A19-491C-998C-E33A42175A45@gmail.com>
 <1503817368.21878.15.camel@ronnypfannschmidt.de>
 <CA+RQFfebaN20rXyX0en=dEb=FZ9zXif3AUQm8RiuWRvTZFWChQ@mail.gmail.com>
 <63b2232b-96f7-2402-f98d-c08dfaf23973@ronnypfannschmidt.de>
 <87shgaup5e.fsf@devork.be>
Message-ID: <CA+RQFfes4BFvU3gOdNRRwUn5PbHZkOoxiT9y2nSYH2Doc7-TxA@mail.gmail.com>

On Tue, Aug 29, 2017 at 4:53 PM Floris Bruynooghe <flub at devork.be> wrote:

> Hello,
>
> RonnyPfannschmidt <opensource at ronnypfannschmidt.de> writes:
> > Am 29.08.2017 um 15:18 schrieb Bruno Oliveira:
> >> On Sun, Aug 27, 2017 at 4:04 AM Ronny Pfannschmidt
> >> <opensource at ronnypfannschmidt.de
> >> <mailto:opensource at ronnypfannschmidt.de>> wrote:
> >>     what i imagine is an api like this:
> >>
> >>     node.find_marks() -> iterates over all marks of all nodes
> >>     node.find_marks('name') -> iterates over all marks that have a name
> >>     node.find_marks(SomeType) -> iterates over all marks that are
> instaces
> >>     of the type
> >>
> >>
> >> This seems reasonable. Minor suggestion, perhaps name the methods
> >> "iter_marks" instead? Seems better based on the descriptions of each one
> >> ("iterates over all marks...")
> >
> > i'd like to bikeshed on the names a bit in order to give them exactly
> > the meaning they should have - perhaps i should split iteration and
> > filtering even
>
> In general I'd agree that splitting the iteration and filtering might be
> more pythonic, also python has generally moved away from calling things
> "iter_*" I think.  Lastly I find the Node.find_marks_with_nodes()
> variation rather clumsy as well.
>
> After thinking about this a bit the best I can come up with is the
> simple Node.marks() method.  As is common in Python it takes no
> arguments and does not filter, it just returns an iterator.  To make
> that work you'd also need to change what object the iterator returns, I
> imagine something like this:
>
> class MarkHolder:
>     name = 'old_mark_name' or None
>     obj = SomeType or whatever obj the old ones are
>     origin = Node
>
> (As an aside I'm guessing this class would be a prime candidate to be
> marked @attr.s thing)
>
> While you get an extra layer it's both rather Pythonic in the API with
> respect to the behaviour of the iterator method as well as py.testy with
> the use of holder.obj.  (I'm not sure if "py.testy" is generally
> perceived as a desirable property or not ;-))
>
>
> >>     node.push_mark(markobj) -> pushes a mark to a node, always requires
> a
> >>     mark object wither taken from pytest.mark or a new style one
>
> This method I do like, it should probably come with a symmetric
> Node.pop_mark() as well which would mirror dict.pop() behaviour.
>
>
> >>     following up the evaluation of skip marksfor example would look like
> >>     this:
> >>
> >>     for mark in node.find_marks('skip'):
> >>        if eval_mark(node, mark):
> >>           pytest.skip(mark.args)
>
> for mark in (m for m in node.marks() if m.name == 'skip'):
>     ...
>
> >>     a more complex marker could be wored the following
> >>
> >>     for orgin, blocker in node.find_marks_with_node(Blocker):
> >>        blocker.maybe_trigger_outcome(orgin=orgin, current=node)
>
> for mark in (m for m in node.marks() if isinstance(m.obj, Blocker)):
>     mark.obj.maybe_trigger_outcome(origin=mark.origin, current=node)
>
> Having written these examples without any filtering API I do admit I'm
> doubting my earlier evaluation about this being a more Pythonic API.  It
> certainly is a lot more writing and probably even harder to read as
> well.  But I thought I'd still send the mail as it's still useful food
> for thought.
>

Not sure, I find the examples quite readable if we name the expressions:

```python
skip_marks = (m for m in node.marks() if m.name == 'skip')
for mark in skip_marks:
    ...
```

```python
blocker_marks = (m for m in node.marks() if isinstance(m.obj, Blocker))
for mark in blocker_marks:
    mark.obj.maybe_trigger_outcome(origin=mark.origin, current=node)
```

So I think the idea is worthwhile. Also, it is simpler to add more ways to
filter the API later than remove something later, so there's that to
consider as well.

But I like that we seem to agree on the general direction of the API.

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