【问题标题】:Google Python style guide谷歌 Python 风格指南
【发布时间】:2011-07-22 13:20:53
【问题描述】:

为什么Google Python Style Guide 更喜欢列表推导和 for 循环而不是过滤、映射和归约?

已弃用的语言功能: ... “使用列表推导和 for 循环代替过滤、映射和归约。”

给出的解释是:“我们不使用任何不支持这些功能的 Python 版本,因此没有理由不使用新样式。”

【问题讨论】:

    标签: python


    【解决方案1】:

    我认为这是因为不是每个人都知道如何很好地使用这些功能;对于不熟悉的人来说,可读性可能会受到影响。此外,for 循环和列表推导被广泛使用且易于理解;尽管后者来自函数式编程,就像mapfilterreduce,但它可以很好地镜像列表和for 循环。在任何情况下,填充 lambda 或定义一个函数只是为了与 map、filter 或 reduce 一起使用会很烦人,特别是因为 lambda 只能是一个表达式,而一个函数可能会使您的代码混乱。反正你不需要它们; map(func, seq) 只是 [func(x) for x in seq]filter 只是带​​有 if 组件的列表理解。 reduce 可以通过 for 循环来完成。

    简而言之,for 和列表推导式更清晰,并且在大多数情况下它们提供基本等效的功能。

    【讨论】:

      【解决方案2】:

      mapfilter 的功能远不如它们的列表理解等价物。 LC可以一步完成过滤和映射,它们不需要显式函数,并且由于其特殊的语法可以更有效地编译

      # map and filter
      map(lambda x:x+1, filter(lambda x:x%3, range(10)))
      # same as LC
      [x+1 for x in range(10) if x%3]
      

      没有理由更喜欢映射或过滤而不是 LC。

      reduce 略有不同,因为没有等效的 LC,但与普通的 for 循环相比也没有太大优势。

      【讨论】:

      • map() 仍然可以说更好的典型用例是将现有的单参数函数应用于序列,例如map(str, seq)。这种操作是它最终保留在 Python 3 中的原因。
      【解决方案3】:

      列表推导通常被认为比filtermapreduce 更“pythonic”。

      另请参阅 Python 创建者 Guido van Rossum 的 article

      就在样式指南中的“已弃用的语言功能”下提交此内容而言,显然有计划在 Python 3 中弃用 filtermapreduce(请参阅上面引用的 article)。

      其中一些计划最终改变了。 reduce 已从内置函数中删除(并移至 @987654323@ 模块),但 filtermap 仍然是 available 作为内置函数。

      【讨论】:

      • functools 本身就是标准库的一部分。 reduce() 的降级实际上只是让它不再是内置的。
      【解决方案4】:

      Google Python Style guide不说

      更喜欢列表推导和 for 循环,而不是 filter、map 和 减少

      而是完整的句子,

      使用列表推导和 for 循环代替过滤器和映射 when 无论如何,函数参数将是一个内联的 lambda。 (我的重点)

      因此,例如,不建议您完全避免使用map -- 仅此而已

      [expression(item) for item in iterable] 
      

      优于

      map(lambda item: expression(item), iterable)
      

      在这种情况下,很明显列表推导式更加直接和可读。

      另一方面,像这样使用map 并没有错:

      map(str, range(100))
      

      而不是冗长的

      [str(item) for item in range(100)]
      

      开机效果不错:

      In [211]: %timeit list(map(str,range(100)))
      7.81 µs ± 151 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
      
      In [215]: %timeit [str(item) for item in range(100)]
      10.3 µs ± 3.06 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
      

      【讨论】:

      • +1 用于性能比较...有趣的是地图在这种情况下运行得更快。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-02-14
      • 2010-12-06
      • 2017-06-10
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多