Paul Rubin <no.email@nospam.invalid>: > Steve D'Aprano <steve+pyt...@pearwood.info> writes: >> For loops and comprehensions (in Python) are inherently procedural, > > Sure, and floating point arithmetic is inherently imprecise and > doesn't follow the associative laws for either addition or > multiplication. There are times when we have to be aware of those > details. Usually, though, we want to act as if they represent the > mathematical reals, and we read Python statements involving floats as > if they were mathematical statements involving reals.
Nothing prevents you from using Python's comprehensions that declarative way. The question is, is it bad style—or even an error—to rely on the execution order of the comprehension loops? Is a Python implementation allowed to parallelize or otherwise reorder the evaluation loop? Unfortunately, the spec is rather vague: they are computed via a set of looping and filtering instructions [...] the elements of the new container are those that would be produced by considering each of the for or if clauses a block, nesting from left to right, and evaluating the expression to produce an element each time the innermost block is reached. <URL: https://docs.python.org/3/reference/expressions.html#display s-for-lists-sets-and-dictionaries> Thus, the scholastic debate may rage on. > Similarly we occasionally have to be aware of the procedural nature of > Python list comprehensions, but most of the time we think of them in > terms of the mathematical abstraction they are designed to resemble. I understand your concern. With the introduction of a "while" in the syntax, the beautiful illusion would be shattered. However, I think the concept of a generator expression is more fundamental in Pythonic thinking. Also, since Python has chosen to specify the precize execution order in: { f(g(), h()) * k() : z() } I would think comprehensions would be put in a similar straitjacket. Marko -- https://mail.python.org/mailman/listinfo/python-list
