列表理解语法

本文介绍了列表理解语法的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 有没有人发现列表理解语法笨拙？ 我喜欢它，因为它是一个表达式而不是一系列语句， 但是它看起来有点难以维持。 例如你可以这样做： result = [] 列表中的元素： 如果元素[0：4] == ''blah''： result.append（element.replace（''blah''，''moof''）） 或者只是： result = [element.replace（''blah''，''moof''）列表中的元素如果 元素[0：4] ==''blah''] 在某些情况下，第二种看起来更干净，但它的可维护性较差。它倾向于促进长线。这一切似乎都在一起运行等等。并且 通常你需要添加另一个条件或修改它，看起来更好 使用第一种方式，即使它有丑陋的额外init（并且会 导致比列表理解更多的分配？因为它不知道 大小的蝙蝠？） 我我赞成像我认为Guido在风格指南中所说的短线。我好像每条线路一样简单到不需要任何思考就读它， 例如 我更喜欢： x = c（d，e） y = f（g，h） z = b（x，y） w = a（z） 这样的东西： w = a（b（c（d，e） ），f（g，h））） 它更易于维护，当你需要进行更改时，只需插入一行， 而不是必须解码一个表达式。 沿着同样的路线，分开一些东西似乎更容易维护。 你可以这样做： result = [ element.replace（''blah''，''moof''） 列表中的元素 如果元素[0：4] =='''blah''] 我猜，但这对我来说似乎很尴尬。看起来太像for循环和 一个if，然后值在顶部，这对我来说很有趣。 （奇怪地把它放在一行上没有看起来很有趣，但它可以读得更少。或许我只需要习惯它。您更喜欢哪个？ 评论？ MB 解决方案 Moosebumps>有没有人在这里找到列表理解语法尴尬？ ... Moosebumps>我赞成像我想的那样短线Guido说 Moosebumps>在风格指南中。我喜欢每一行都这么简单。 Moosebumps>至于不需要任何思考阅读它， 你需要考虑有几个行所涉及的总复杂性。当您看到列表理解时，您知道会发生什么 - 应用于列表的转换和/或过滤。因此，你可以轻松地阅读和写出野兽。 LC'也鼓励列表转换/过滤方法来解决问题，我觉得这绝对是出色的。手动将元素附加到列表是很乏味的，特别是如果问题确实是由LC解决的陈规定型问题（有趣的是，大多数问题都是;-)。 Moosebumps>你可以这样做： Moosebumps>结果= [ Moosebumps> element.replace（''blah''，''moof''） Moosebumps>列表中的元素 Moosebumps>如果元素[0：4] =='''blah''] Moosebumps>我想，但这对我来说似乎很尴尬。看起来太多 Moosebumps>像for循环和if，然后值是在Moosebumps>顶部，这对我来说很有趣。 （奇怪地把Moosebumps>它放在一行上看起来并不好笑，但它更少 Moosebumps>可读。）也许我只需要习惯它。 Moosebumps>您更喜欢哪一种？ 这只是习惯它的问题。不可否认，LC'有时会让新手感到困惑，但他们就是这种功能的一个例子，新手和非新手友好之间的权衡确实得到了回报。 有人接近25年的编程语言经验 及其含义，我觉得列表理解是不可理解的。 就我个人而言，我认为我的学习受到文件的抑制，这些文件似乎是由列表推理的语法驱动而不是 执行模型以及如何识别它的时间适用于那个 模型。 我发现多条短线实际上更容易理解，因为它将b / b转化为一种常见的心理因素我的模型。当前语法为 那些理解'让我想起了APL，这是一种很棒的语言 如果你想的只是向量。 我会承认这个讨论已经让我试图再次学习列表 comprehensions，因为我正试图解决一个问题，即过滤数据字典的b $ b基于谓词的元素选择 单个元素和/或从上一个谓词列表开始的偏移量的谓词。 顺便说一下，同样受文件限制的是生成器， 迭代器和分析时基。我有很多困难 取出模型抽象，正如我上面所说的那样，了解将 应用于问题空间的位置。 几乎是定义pythonic的原因。为我做事的方式这些天。 这并不意味着以任何形式或形式挑选你，但我的 经验一直是你发现自己不得不用语言来思考时，你并没有真正解决正确的问题而且 more可能会使用一系列魔术技巧来混淆和惊讶其他人并且可能确保工作安全。 如果您的模型可以独立于语言实现 并且您可以用问题自然而然的方式表达问题， 您总是可以为跟随您的人提供更好的解决方案 以及机器。 概括，不要pythonize。 --- eric Does anyone here find the list comprehension syntax awkward? I like it because it is an expression rather than a series of statements,but it is a little harder to maintain it seems. e.g. you could do: result = []for element in list:if element[0:4] == ''blah'':result.append( element.replace( ''blah'', ''moof'' ) ) or just: result = [ element.replace( ''blah'', ''moof'' ) for element in list ifelement[0:4] == ''blah'' ] The second looks cleaner in some cases, but it is less maintainable. Ittends to promote long lines. It all seems to run together and such. Andoften you would need to add another condition or modify it, it seems betterto use the first way even though it has the ugly extra init (and which wouldcause more allocs than the list comprehension? because it wouldn''t know thesize off the bat?) I am in favor of short lines like I think Guido said in the style guide. Ilike each line to be so simple as to not require any thinking reading it,e.g. I prefer: x = c( d, e )y = f( g, h )z = b( x, y )w = a( z ) to stuff like this: w = a( b( c( d, e ), f( g, h ) ) ) It is more maintainable, when you need to make a change, just insert a line,rather than having to decode an expression. Along the same lines, it seems more maintainable to split things up. You could do: result = [element.replace( ''blah'', ''moof'' )for element in listif element[0:4] == ''blah'' ] I guess, but that seems awkward to me. Looks too much like a for loop andan if, and then the value is at the top, which reads funny to me.(Strangely putting it on one line doesn''t read as funny, but it is lessreadable.) Maybe I just have to get used to it. Which do you prefer?Comments? MB 解决方案 Moosebumps> Does anyone here find the list comprehension syntax awkward? ... Moosebumps> I am in favor of short lines like I think Guido said Moosebumps> in the style guide. I like each line to be so simple Moosebumps> as to not require any thinking reading it, You need to think of the total complexity involved with having several lines. When you see a list comprehension, you know what to expect - transformation and/or filtering applied to a list. Therefore, you can easily read and write out the beast. LC''s also encourage the list transformation/filtering approach to problems, which I find absolutely splendid. Appending elements to a list manually is tedious, especially if the problem really is a stereotypical problem solved by a LC (and interestingly, most problems are ;-). Moosebumps> You could do: Moosebumps> result = [ Moosebumps> element.replace( ''blah'', ''moof'' ) Moosebumps> for element in list Moosebumps> if element[0:4] == ''blah'' ] Moosebumps> I guess, but that seems awkward to me. Looks too much Moosebumps> like a for loop and an if, and then the value is at Moosebumps> the top, which reads funny to me. (Strangely putting Moosebumps> it on one line doesn''t read as funny, but it is less Moosebumps> readable.) Maybe I just have to get used to it. Moosebumps> Which do you prefer? It''s just a matter of getting used to it. Admittedly LC''s are sometimes confusing for newbies, but they are an example of such a feature where the tradeoff between newbie and non-newbie friendliness has really paid off. as someone approaching 25 years experience with programming languagesand their implications, I find list comprehension''s incomprehensible.Personally I think my learning is inhibited by the documentation whichseems driven by the syntax of list comprehensions rather than theexecution model and how to recognize when it''s appropriate to apply thatmodel. I find multiple short lines actually easier to comprehend because ittranslates into a common mental model of mine. The current syntax forthose comprehension''s reminds me of APL which was a wonderful languageif you thought in nothing but vectors. I will admit this discussion has goaded me into trying to learn listcomprehensions again as I am trying to solve a problem which isfiltering a dictionary of data elements based on predicates selectingindividual elements and/or predicates on the offset from the start ofthe previous predicate list. By the way, similarly hampered-by-the-documentation are generators,iterators, and profiling time bases. I''m having a lot of difficultypulling out model abstractions, and as I said above, understanding whereto apply them in problem spaces. Now that genexps are coming around, you''ll be facing even bigger payoffs. So just keep using them, even if they might not feel as maintanable at the moment. LC''s (and genexps even to a bigger extent) are pretty much what defines the "pythonic" way of doing things for me these days. this is not meant to be picking on you in any way shape or form but myexperience has been that any time you find yourself having to "thinkingin the language", you are not really solving the right problem and aremore likely using a collection of magic tricks to confound and amazeothers and possibly insure job security. if you have models that can be implemented independent of the languageand you can express a problem in terms that are natural to the problem,you invariably have a better solution for the people following you aswell as the machine. generalize, don''t pythonize. ---eric 这篇关于列表理解语法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！