parametrize with marked callable objects

[schipiga]

To fix #750

[schipiga]

@pfctdayelise, I suppose, you may review my pr, mayn't you?

[schipiga]

Hey @pfctdayelise, @nicoddemus, @RonnyPfannschmidt, @hpk42 please review my pr. I'm inclined to believe, I had fixed a nice bug :)

[RonnyPfannschmidt]

This fix is actually very problematic

Imagine using the same function as xfail in one call and as normal in an other call

The mark would be carried trough and smear across usages

@hpk the usage of marks in parametrization seems full of inconsistencies

We should extend the api for consistent non decorator usages

[schipiga]

@RonnyPfannschmidt , can post a chunk of problematic code example, please? I'm afraid I can misinterpret:

Imagine using the same function as xfail in one call and as normal in an other call

[RonnyPfannschmidt]

On usage as marked parametrization a function is modified and can no longer be used in normal parametrization since it will carry on the xfail

Applying xfail to a function/class will modify that function/class

That problems is elevated since one of Python shortcomings is using the call protocol for decoration

So we cannot know if a call to a mark is meant to create a markinfo or a decoration of the function/class

[schipiga]

@RonnyPfannschmidt , thank you for clarification. Yep, that's not pleasant moment.

[nicoddemus]

Hmmm given that, I think this solution should be withdrawn, no?

[schipiga]

@RonnyPfannschmidt do I understand right, that is core of problem, that MarkDecorator.__call__ returns modified the same callable object? And If we will find a proper way to clone function and class, it will solve the problem? I suppose, types.FunctionType and types.ClassType can help here.

[schipiga]

Hey @RonnyPfannschmidt, @nicoddemus, I had updated my pr. Now MarkDecorator.__call__ returns modified clone of callable object.
At travis-ci 2 images were broken. Can you please restart the build? Unfortunately I don't have enough rights.

[schipiga]

TravisCI was triggered via reopen pr, but AppVeyor wasn't ;(

[RonnyPfannschmidt]

the idea with the clone is a really cool hack

however i fear it might create some issues down the line
i would like to have a discussion about the details and implications to gain a better understanding

would you perhaps be available for chat on irc or a video conference?
for myself ts a bit tricky (im currently traveling for a cross country move flat hunt)

[schipiga]

@RonnyPfannschmidt I would prefer to chat, my speaking english isn't good. When would you like to meet? I'm in Moscow time zone. Tomorrow is sunday and I will be free after 3 p.m. local time. But in weekdays I'm free after 9 p.m. only

[RonnyPfannschmidt]

Unfortunately I can't make it today

[nicoddemus]

@sergeychipiga @RonnyPfannschmidt any news on this guys?

[RonnyPfannschmidt]

no, this is currently lingering around - i'm not sure i can catch up with @sergeychipiga before the sprint

this one is in part dependent on mark-refactor - which i ope to catch up with before the sprint

[RonnyPfannschmidt]

closing this one, i think the only sane way to mark a parameter is to use a object thats a 2-tuple of value, marks - i#ll prototype a implementation later, it should be exposed as something like pytest.marked_parameter(value, marks)