复杂策略中的@composite vs flatmap

Question

假设允许两种不同的方式来定义派生策略，@composite 和 flatmap。据我所知，前者可以做后者可以做的任何事情。但是，numpy arrays 策略的 implementation 谈到了一些隐性成本

    # We support passing strategies as arguments for convenience, or at least
    # for legacy reasons, but don't want to pay the perf cost of a composite
    # strategy (i.e. repeated argument handling and validation) when it's not
    # needed.  So we get the best of both worlds by recursing with flatmap,
    # but only when it's actually needed.

我认为这意味着更糟糕的收缩行为，但我不确定，而且我在其他任何地方都找不到这方面的记录。那么我什么时候应该使用 @composite，什么时候使用 flatmap，什么时候应该像上面链接的实现那样走这条中途路线？

Answer 1

@composite 和 .flatmap 确实是完全等价的——任何你可以用一个做的事情你也可以用另一个做，而且它们也有相同的性能。

我实际上写了那个评论，原因是我们只是有时想使用flatmap/composite，但总是想仔细验证我们的逻辑。按照我设置的方式，我们可以通过使用 .flatmap 避免多次调用验证器——如果我们想使用 @composite，这将需要第二个函数定义。

（还有一个 API 风格的问题，因为这些论点几乎总是价值观，但有时可能是策略。我们现在禁止此类 API 主要是因为混淆 arrays() 导致，赞成让用户自己编写 .flatmaps)

复杂策略中的@composite vs flatmap

@composite vs flatmap in complex strategies

python

property-based-testing

python-hypothesis