复杂策略中的@composite vs flatmap答案

【问题标题】：@composite vs flatmap in complex strategies复杂策略中的@composite vs flatmap
【发布时间】：2020-04-08 02:29:33
【问题描述】：

假设允许两种不同的方式来定义派生策略，@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，什么时候应该像上面链接的实现那样走这条中途路线？

【问题讨论】：

标签： python property-based-testing python-hypothesis

【解决方案1】：

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

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

（还有一个 API 样式问题，因为这些参数几乎总是值，但有时可能是策略。我们现在禁止此类 API 主要是基于 arrays() 造成的混乱，有利于让用户编写自己的.flatmaps)

【讨论】：

有道理。你能解释一下“验证者”是什么意思吗？在文档中搜索validator 只会产生两个命中，这两个都不能真正解释任何事情。不以策略为论据，而是以.flatmap 一切为公认的最佳实践吗？
在内部，我们检查例如所有参数都是允许的类型 - 但显然一旦验证器通过一次，我们不需要为每个示例再次运行它。最佳实践是任何特定参数都可以接受一个值xor 策略。例如在st.datetimes() 中，min_value 必须始终是日期时间（绝不是策略），timezones 必须始终是tzinfo 对象的策略（绝不是这样的对象）。决定使用哪个是基于频率并比较st.just(...)与x.flatmap(...)的不便。