Steve D'Aprano <steve+pyt...@pearwood.info> writes: > On Thu, 17 Aug 2017 12:28 am, Ben Finney wrote: > > > Steve D'Aprano <steve+pyt...@pearwood.info> writes: > > > >> If he wanted declarative semantics, why didn't he argue for > >> declarative syntax like "select...where", instead of choosing > >> procedural syntax which matches the actual procedural semantics given? > > > > The syntax “f(foo) for foo in bar if baz(foo)” is nicely declarative. > > Do you consider [a Python ‘for’ loop] declarative?
No, that is a syntax that can only mean iteration over the *distinct statements* in the block. > My understanding of "declarative" agrees with Wikipedia: Thanks. Mine does too. > For-loops are a classic example of explicitly specifying control flow, > so I'm surprised that you seem to think they are declarative. The Python for loop syntax specifies control flow. The Python list comprehension syntax does not specify control flow. The expression “f(foo) for foo in bar if baz(foo)” is not expressing control flow, it is expressing a single conceptual operation. A collection goes in, a single conceptual operation is performed, a collection goes out. The control flow is not specified. > SQL's SELECT ... WHERE is one of the canonical examples of declarative > programming: > > SELECT * > FROM Book > WHERE price > 100.00 > > returns matching books (those with a price over 100) in arbitrary > order (unless you specify the "ORDER BY" clause). But more importantly > than the order of results, the order of data accesses is not specified > by the SELECT statement. Nor is the order of data accesses specified by Python's comprehension syntax. In both cases, of course, implementations *do* perform smaller-grained operations in a specific control flow. You'll even find that order of operations described in the documentation, for SQL implementations and for Python, respectively. > for row in Book: > if row.price > 100: > print(row) # for example > > I think that is specifying the control flow, and therefore not > declarative. Do you agree? Yes, I agree. > [...] > > I'm responding to the proposal by pointing out that, unlike today's > > Python, the proposed behaviour would violate those semantics. > > In what way? By inserting a semantic of iteration over multiple operations, into what is otherwise an expression with declarative semantics. > Do you feel the same way about itertools.takewhile? The functions in the ‘itertools’ module are not expressing a declarative single operation; they are expressing an iteration of multiple operations. List comprehensions, in their syntax, strongly connote a single declarative operation. This makes them different from iteration syntax. -- \ “Shepherds … look after their sheep so they can, first, fleece | `\ them and second, turn them into meat. That's much more like the | _o__) priesthood as I know it.” —Christopher Hitchens, 2008-10-29 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
