Using Fable plugins for XUnit attributes to pytest decorators

[dbrattli]

What I want is to get better XUnit handling for Fable.Python. The idea is to use Fable plugins for translating the XUnit attributes to pytest decorators:

[<Fact>]
let ``it works`` () =
    Assert.True(true)

The Fact attribute should make sure the test function starts with test or else it will prepend test.

@pytest.mark.fact
def test_it_works () =
    assert_true(True)

The Theory and ÌnlineData attributes should translate to parameterize lists.

[<Theory>]
[<InlineData(3)>]
[<InlineData(5)>]
[<InlineData(6)>]
let ``inline data works`` (value: int) =
    Assert.True(IsOdd(value))

@pytest.mark.theory
@pytest.mark.parametrize("value", [3, 5, 6])
def test_inline_data_works (value: int) =
    assert_true(True)

I'm trying to do this using Fable plugins. The Transform member has signature MemberDecl -> MemberDecl so I can see the functions and get the attributes, but since I cannot prepend anything (e.g Fable.Emit), I need to return e.g a nested function that I need to know in Fable2Python.fs that these nested functions should then be rewritten as decorators. So I need to give some kind of hint. Would it be ok to use MemberDecl.Tags for this. E.g. use a tag "decorator" or is the .Tags ment for something else? Or is there a better way to do this?

[alfonsogarciacaro]

Yes the idea of Tags is basically "pass any information you want". I did it like that so we could add new features accessible from the plugins without having to change the AST. For example, Feliz.ReactComponent plugin passes the "export-default" tag to mean the member should be exported as default. Because this kind of info is language-specific and not explicit in the Fable AST, the tag is handled in Fable2Babel.

[dbrattli]

Thanks for the quick response @alfonsogarciacaro. I'll try to see if can get this to work. Would be great to have some better / common test handling for Fable.Python, both XUnit and Expecto style.

[dbrattli]

One more question. When is the TransformCall(compiler, memb, expr) override invoked?

[alfonsogarciacaro]

Whenever the method decorated with the attribute is being called. In this case, because tests are not called directly I assume you don't need it so you can just return the expr argument directly.

[dbrattli]

@alfonsogarciacaro Not really sure how to proceed here. Translating [<Theory>] and [<InlineData>] into nested functions in order to make decorators out of them is a bit complicated. Adding the decorator itself as a Tag feels a bit too stringly typed.

Using the new DecoratorAttribute is also possible, but the generated becomes nested. Both JS (experimental) and Python have decorators so it would be nice if we could generate proper decorators. E.g for code such as:

type MeasurePerformanceAttribute () =
    inherit Py.DecoratorAttribute()
    
    override _.Decorate(fn: Py.Callable) =
        Py.argsFunc(fun args -> 
            let sw = System.Diagnostics.Stopwatch()
            sw.Start()
            let res = fn.Invoke(args)
            sw.Stop()
            res
        )

[<MeasurePerformance>]
let myExpensiveCalculation x y = x + y

This generates the following Python:

class MeasurePerformanceAttribute:
    def __init__(self, __unit: Literal[None]=None) -> None:
        pass

    def Decorate(self, fn: Callable[..., Any]) -> Callable[..., Any]:
        def _arrow3(args: Array[Any]) -> Any:
            sw: Any = StopWatch()
            sw.start()
            res: Any = fn(*args)
            sw.stop()
            return res

        return lambda *args: _arrow3(args)


MeasurePerformanceAttribute_reflection = _expr4

def MeasurePerformanceAttribute__ctor(__unit: Literal[None]=None) -> MeasurePerformanceAttribute:
    return MeasurePerformanceAttribute(__unit)


def _arrow5(x: int, y: int) -> int:
    return x + y


my_expensive_calculation: Callable[[int, int], int] = MeasurePerformanceAttribute().Decorate(_arrow5)

However what I would like to generate is something like below. An idea would be to add decorators as a property of MemberFunctionOrValue, and then have plugins or applyDecorator to add the decorator there instead of calling. Then e.g Fable2Python could choose if the decorators should be expanded into calls or use native language decorators.

class MeasurePerformanceAttribute:
    def __init__(self, __unit: Literal[None]=None) -> None:
        pass

    def __call__(self, fn: Callable[..., Any]) -> Callable[..., Any]:
        def _arrow3(args: Array[Any]) -> Any:
            sw: Any = StopWatch()
            sw.start()
            res: Any = fn(*args)
            sw.stop()
            return res

        return lambda *args: _arrow3(args)


MeasurePerformanceAttribute_reflection = _expr4

def MeasurePerformanceAttribute__ctor(__unit: Literal[None]=None) -> MeasurePerformanceAttribute:
    return MeasurePerformanceAttribute(__unit)


@MeasurePerformanceAttribute()
def my_expensive_calculation(x: int, y: int) -> int:
    return x + y

Any ideas?

[alfonsogarciacaro]

Sorry @dbrattli, not sure I understand what's the problem with nested functions. With the plugins you process the AST at compile time and can replace the declaration with anything you want. With the DecoratorAttribute you process the function at runtime (during initialization) and replace it with a value.

About "actual" JS/Python decorators. In the case of JS there have been two problems so far: 1) afaik there are still two competing proposals for JS decorators so if we support one, there's a risk they end up implementing the other (I think something like this is happening with TS decorators), 2) JS decorators are very flexible because you can use any expression, so it's difficult to represent them with .NET attributes.

I wonder if we can start implementing decorators in a hacky way like this:

[<Emit("@$0")>]
let decorate (decorator: obj): unit = ()

// To be used like

let measurePerformance fn = ...

decorate measurePerfomance
let myExpensiveCalculation x y = x + y

This cannot be used with class members, but it may be an easy way to experiment.