[pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

2018-03-20 15:07 GMT+01:00 Floris Bruynooghe <flub at devork.be>:

> On Tue, Mar 20 2018, Ronny Pfannschmidt wrote:
>
> > 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <flub at devork.be>:
> >> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote:
> >> > I also did deprecate markinfo attributes,
> >> > so everyone using them will get deprecation warnings.
> >>
> >> That's a lot of people probably.  How long are we giving users for this?
> >> ​
> >>
> >
> > ​the support for accessing them can be kept for quite a while,
> > everyone using them will be told to use the new api
> > i would like to remove it at the beginning of 2019
>
> Ok, they're currently marked as "deprecated in 4.0".  So we're not
> releasing 4.0 until then?  Or are we just keeping our options open here
> and extending a deprecation is easier then reducing it?
>

​exending is easier than reducing. - but im not opposed to killing it
earlier​



>
> >> > as far as i'm concerned, markinfo attributes where never ever a
> correct
> >> way
> >> > to handle distinct marks and quite a few bugs in pytest came from
> using
> >> > combined marks in markinfo instead of distinct marks.
> >>
> >> A short summary of these issues would help loads :)
> >>
> > ​basically MarkInfo objects are subject to marker transfer bugs, marker
> > smearing and everything wrong with marks these days
> > they are one of holgers infamous minimal changes that basically ensured
> we
> > never ever had correctly working marks
> > from the time we had support for more than one marker of the same name,
> and
> > it got worse by the addition of marker transfers
> > (for context - pytest marks started as thing to update test function
> > __dict__ with its keyword arguments,
> > they never got de-tangled from that messy legacy, and that was a major
> > source of really bad bugs)
>
> Thanks!  Could you give an example of a marker transfer bug?  I've never
> run into those myself so I'm not sure I understand what this is.  I
> assume something like this will trigger weird cases:
>
> @pytest.mark.mark0
> class Foo:
>
>     @pytest.mark.mark1
>     def test_foo(self):
>         pass
>
>     @pytest.mark.mark0('foo', a='a')
>     def test_bar(self):
>         pass
>
> So the new API to inspect this is (in some pseudo-code like fashion):
>
> <Item name=test_foo>.get_marker('mark0') -> Mark(name='mark0')
> <Item name=test_foo>.get_marker('mark1') -> Mark(name='mark1')
> <Item name=test_bar>.get_marker('mark0') -> ??
> list(<Item name=test_foo.find_markers('mark0')) -> [Mark(name='mark0')]
> list(<Item name=test_bar.find_markers('mark0')) -> ??
>
>
​class TestA(object):
   def test_fun(self):
      pass


@pytest.mark.evil
class TestB(TestA):
  pass

-> after collection TestA.test_fun will have a evil marker​





> Also, can I iterate over all the markers on a node?
>
>
> ​for now, explicitly not,

i'm open to introducing it when someone demonstrates a real practical
use-case​
--
​ Ronny​



> Thanks for educating me!
> Floris
>



-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180320/c429bac8/attachment-0001.html>