Re: [Python-ideas] Python-ideas Digest, Vol 138, Issue 32

Hi all! Really interesting discussion on here. Personally I feel that PEP 572, as it stands, undermines the readability of the language, in particular for those new to the language, programming. I have issue with both the in-expression assignment, and the current proposed operator approach. Below is a modified version of a comment I made on a Reddit thread about this. I think the first point is that, beginners often read more code than they write - to build a mental picture of how the language works, and to build their solution from existing parts. Whether this is a good means of learning, or not, it's quite commonplace (and I learned using such a method). If this PEP passes, you will find people use the syntax. And it may well end up being disproportionately used in the early stages because of "new feature" semantics. Here is an extract from the Wikipedia A* search function reconstruct_path(cameFrom, current) total_path := [current] while current in cameFrom.Keys: current := cameFrom[current] total_path.append(current) return total_path In Python 3.7, that looks like this: def reconstruct_path(cameFrom, current): total_path = [current] while current in cameFrom.keys(): current = cameFrom[current] total_path.append(current) return total_path (of course it's not entirely Pythonic), but the point is - the pseudo code is designed to be semantically readable, and the Python code is very similar However with PEP572, now, the beginner will encounter both := assignments, and = assignments. When to use which one? Now they need to learn the edge cases / semantic differences between expression and statement explicitly, rather than picking this up as they go. I am not making this argument because I think that this is they best way to learn a programming language, I'm simply arguing that there is more cognitive overhead when unfamiliar with the language, in order to use the appropriate feature. In terms of implementation, it's especially odd that the current proposal (AFAICT) only binds to a name, rather than an assignment target. This feels very wrong, despite the fact that I can understand why it is suggested. I feel like the Python 3 series in particular has been making syntax more uniform, so that there aren't quirks and edge cases of "this only works in this context" (besides async, of course), which is one of the things that makes Python so expressive. Furthermore, with this PEP, assignment can now happen inside of expressions - and so one of the most fundamental benefits of expressions being effectively immutable in terms of local names is lost. In terms of prevalence, I don't think that these situations do occur all that often. I definitely agree that regex is the prime candidate for this kind of syntax. However, in the examples given (matching 3+ regexes), I would use a loop for simplicity anyway. When it comes to assigning to a result that is only used in the conditional block, this is certainly a case that benefits from the PEP. -------------------------------------------------------- If, however, the motivation for the PEP was deemed significant enough that warrant its inclusion in a future release, then I would like to suggest that the keyword approach is superior to the operator variant. In particular, I prefer the `where` to the `given` or 'let' candidates, as I think it is more descriptive and slightly shorter to type ;) Thanks! Angus Hollands

On 6 May 2018 at 07:59, Angus Hollands <goosey15@gmail.com> wrote:
Aside from an API naming conflict with NumPy, the key problem with using "where" for this purpose is that "where" is explicitly used to name *filtering* clauses in SQL, NumPy, and other contexts ("having" is used in a similar way for filtering on SQL aggregate groups). So in "[(x, y, x/y) for x in data if y where y = f(x)]", having both an "if" clause and a "where" clause makes it look like there are two filters being defined (and a mispelt "==" in the second one), rather than a filter and a name binding. The virtue of "given" is that in any context which uses it, the intended meaning is to associate a name with a value (either directly, as in the mathematical usage, or indirectly, as in the hypothesis API usage), which is exactly the meaning we're interested in here. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 6 May 2018 at 07:59, Angus Hollands <goosey15@gmail.com> wrote:
Aside from an API naming conflict with NumPy, the key problem with using "where" for this purpose is that "where" is explicitly used to name *filtering* clauses in SQL, NumPy, and other contexts ("having" is used in a similar way for filtering on SQL aggregate groups). So in "[(x, y, x/y) for x in data if y where y = f(x)]", having both an "if" clause and a "where" clause makes it look like there are two filters being defined (and a mispelt "==" in the second one), rather than a filter and a name binding. The virtue of "given" is that in any context which uses it, the intended meaning is to associate a name with a value (either directly, as in the mathematical usage, or indirectly, as in the hypothesis API usage), which is exactly the meaning we're interested in here. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
Angus Hollands
-
Nick Coghlan