forwarding as i send it with the wrong sender address
-------- Forwarded Message --------
Subject: Re: [pytest-dev] Proposal: python namespacign for
markings/marker objects
Date: Wed, 19 Oct 2016 17:24:32 +0200
From: Ronny Pfannschmidt <i...@ronnypfannschmidt.de>
To: Floris Bruynooghe <f...@devork.be>, pytest-dev <pytest-dev@python.org>
On 19.10.2016 17:01, Floris Bruynooghe wrote:
> On 7 September 2016 at 10:38, Ronny Pfannschmidt <rpfan...@redhat.com> wrote:
>> Hi all,
>>
>> while trying to turn various internal markers of a work project
>> into public plugins, i noticed a very plain problems - different other
>> plugins used the same generic marker name for different purposes/intents
>>
>> such a flat namespace really doesn't scale
>>
>> as such i would like to propose having marker types and objects as
>> importable objects
>>
>> for example
>>
>> import pytest
>> from pytest_bugzilla import Blocker
>>
>> @pytest.mark(Blocker(123))
>> def test_fun():
>> pass
>>
>> that way we can do both, reuse python name-spacing *and* use more meaningful
>> objects for markings
> I'm rather lukewarm for this proposal to be honest. We already have
> an API which allows creating of mark objects for later re-use:
>
> blocker = pytest.mark.bugzilla_blocker
>
> @blocker
> def test_fun():
> pass
>
> So instead of changing the way way pytest.mark behaves I think it
> might be more interesting to look at alternative ways of creating
> marker objects. E.g. if you could do:
>
> # pytest_bugzilla.py
> class Blocker(pytest.MarkerObject):
> def __init__(self, n):
> pass
>
> # test_fun.py
> from pytest_bugzilla import Blocker
>
> @Blocker(123)
> def test_fun():
> pass
> Then you can still import your marker and you also get more strict
> namespacing since you created a unique object in your module. But the
> benefit is that from the point of view of using markers not much has
> changed. There's just a new way of creating markers.
>
> What do you reckon about such an approach?
The main reason why i introduced the separation between objects and
marking was to prevent a damn unreasonable mess.
The objects that are the metadata put onto a function/object should be
completely unaware of the py.test marking functionality,
this is basics of separation of concern and prevents spaghetti behavior
(like MarkInfo vs Markdecorator leaking into item.keywords and creating
a fun painful mess)
>
> Finally, and I only just remembered, Holger has some lingering code
> somewhere which does something like:
>
> @pytest.marker
> def blocker(n):
> return {'issue no': int(n)} # or whatever object you want your marker to
> be
>
> @pytest.mark.blocker(123)
> def test_fun():
> pass
fixtures and markers are not symmetric and i don't see a reason to make
them be
just for looking similar, currently they are *completely* different ,
and i think that bringing them closer to look more nice will make things
MUCH worse.
they are belonging to different categories of "things" with completely
different desired behaviours.
> This uses symmetry with how we create fixtures, which is nice. But it
> does not solve the namespacing issue, which to some extend also exists
> in fixtures. Just brainstorming to add something namespace like to
> that would be:
>
> @pytest.marker(ns='bugzilla')
> def blocker(n):
> return int(n)
>
> @pytest.mark.bugzilla.blocker(123)
> def test_fun():
> pass
>
> I admit this does not re-use the python module namespaces, which is
> probably a downside.
>
i am strongly opposed to inventing a own name-spacing mechanism there,
it would be another mess like the marker transfer, or the yield tests
execute test code at collection time messes
-- Ronny
> Floris
> _______________________________________________
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
