[pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects

[Ronny Pfannschmidt]

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 <ich at ronnypfannschmidt.de>
To: 	Floris Bruynooghe <flub at devork.be>, pytest-dev <pytest-dev at python.org>



On 19.10.2016 17:01, Floris Bruynooghe wrote:
> On 7 September 2016 at 10:38, Ronny Pfannschmidt <rpfannsc at 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 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/20161020/5f07b71a/attachment.html>