LWN: Comments on "PEP 572 and decision-making in Python"

Yet more evidence for Wadler's law

mina86 — Thu, 19 Jul 2018 16:52:23 +0000

Weird, my Polish layout has ‘ü’ there. ;)

PEP 572 and decision-making in Python

gdiscry — Fri, 13 Jul 2018 22:14:11 +0000

That's the issue with toy examples like mine and the ones in the article. If it's a common pattern there's a pretty good chance that you can do it in a simple, optimized and readable way. And then the reader misses the point because the syntax specific to the common case doesn't apply to more complex code.

A better example for iter would be to read a binary file by chunk using for chunk in iter(lambda: f.read(CHUNK_SIZE), b''):. To my knowledge, there isn't a ready made function or method that does the same, contrary to file.readline and file.__iter__.

We can also see that the code is slightly less readable than the readline example. Furthermore, the complexity increases even more once the stop condition cannot be expressed as a simple equality to a sentinel value.

I have to admit that I find while chunk := f.read(CHUNK_SIZE): more readable than the other ways to do it and it looks like the readability remains good even in more complex cases.

PEP 572 and decision-making in Python

gdamjan — Fri, 13 Jul 2018 19:25:00 +0000

the default iterator of python files actually generates lines

>>> fp = open('/etc/os-release')
>>> next(fp)
'NAME="Arch Linux"\n'

Yet more evidence for Wadler's law

ErikF — Fri, 13 Jul 2018 19:07:30 +0000

"<-" has the same problem as the compound assignment operators in early versions of C (i.e. "=+", "=-", etc.): it's ambiguous in high-traffic places. How would you then do a comparison like "a<-b"?

Yet more evidence for Wadler's law

nix — Fri, 13 Jul 2018 10:47:55 +0000

(Note for clarity: I'm not talking about Thompson's B here, but Abrial's B: <https://en.wikipedia.org/wiki/B-Method>. Whether it was only ever visibly used on French safety-critical systems because it was a formal method, because it was ring-fenced, and had only one implementation, or because like Z it used insane numbers of unprounceable symbols that made it really hard to actually talk about the programs you were writing, I'm not sure. Heck it might just be because it was French and your average Silicon Valley VC doesn't speak much French...)

Yet more evidence for Wadler's law

zdzichu — Fri, 13 Jul 2018 06:12:09 +0000

It's RightAlt+y on my keyboard layout in Linux (Polish).

PEP 572 and decision-making in Python

OrbatuThyanD — Fri, 13 Jul 2018 02:07:21 +0000

having spent 18 months pushing through an incredibly inconsequential pep that got bike-shedded to death (eventually accepted, you python 3.2+ folks are potentially benefiting), i'm oddly not surprised that guido is quitting as bdfl after this. dealing with the python devs on that pep made me never want to write python again.

Yet more evidence for Wadler's law

zblaxell — Fri, 13 Jul 2018 00:36:42 +0000

> Though editors could translate <- into ←, one wonders why you didn't just use <- in the first place and avoid this probably-nearly-universal difficulty.

Indeed, "←" is M-bM-^FM-^P, which is even worse than "<-" at 300 baud. Adoption would be slow for the first 15 years while the C development community waited for Unicode to be invented.

Yet more evidence for Wadler's law

nix — Sun, 08 Jul 2018 15:12:17 +0000

> Someone who came up with a new programming language today would probably not think twice about using “←” for assignment

The lesson of B and Z: if your wonderful new language uses lots of symbols that aren't on people's keyboards, uptake will be slow. (Though editors could translate <- into ←, one wonders why you didn't just use <- in the first place and avoid this probably-nearly-universal difficulty.)

(Mind you, a bigger lesson of B: if you ring-fence a language around with copyrights and everything else you can think of, and allow only one implementation on one platform with no FFI facilities, you can expect not too terribly many people to take it up...)

Yet more evidence for Wadler's law

anselm — Sat, 30 Jun 2018 12:41:52 +0000

The convention of = as the assignment operator and == as the equality operator actually arose when Ken Thompson designed the B programming language, the predecessor of C. B in turn is derived from Martin Richards' programming language, BCPL, which does use := for assignment, but one of Thompson's goals when designing B was apparently “reducing the number of non-whitespace characters in a typical program” [Wikipedia article on B].

Yet more evidence for Wadler's law

HelloWorld — Sat, 30 Jun 2018 07:36:14 +0000

I don't buy that at all. A single additional character per assignment is very unlikely to be a problem, even on a 300-baud tty.

Yet more evidence for Wadler's law

HelloWorld — Fri, 29 Jun 2018 22:59:24 +0000

> That's funny: C's assignment operator being an expression instead of a function is viewed as a source of errors: if (toto = FOO) instead of if (toto == FOO)
The problem here isn't that the assignment is an expression but that is has the type of the left operand. If assignment expressions had type void, you couldn't make that mistake.

Yet more evidence for Wadler's law

nybble41 — Fri, 29 Jun 2018 17:27:29 +0000

> You're splitting hair, the different between a statement and a function which will return always void..

The difference is significant in terms of language design. Unification of statements and expressions does not imply that all expressions must produce a value, any more than a function call—which is always considered an expression in C—must produce a value. The point is merely to avoid having two distinct kinds of syntax. Instead of "statements" and "expressions", where statements can include expressions but not vice-versa, you'd simply have "expressions which return a usable value" and "expressions which return void". A function body would just be a single expression to be evaluated.

Add to that treating 'void' as a standard type with exactly one possible value (and thus no runtime representation), suitable for declaring variables, fields, parameters, etc., and some sort of local variable-binding expression similar to LISP's 'let' form, and you enable much more straightforward and expressive generic programming which currently can only be achieved through nonstandard extensions such as GCC's statement-expressions and __builtin_choose_expr() / __builtin_types_compatible_p().

Yet more evidence for Wadler's law

anselm — Fri, 29 Jun 2018 15:08:29 +0000

Simply changing the names to '=' for equality and something like ':=' for assignment would have eliminated the issue without any change in semantics.

That makes a lot of sense, especially with 20/20 hindsight. It's, however, just as well to remember that when C was invented, the method of choice to talk to your Unix machine (a PDP-11) would have been a 300-baud teletype printer. The original Unix developers were pragmatic people and they wanted to avoid superfluous keystrokes, hence ls and rm instead of list and remove, and, because C programs tend to contain way more assignments than equality comparisons, = for assignment and == for equality. (OTOH, Niklaus Wirth, who invented Pascal at about the same time, was not a pragmatist at all, so Pascal does have := for assignment and = for equality.)

Someone who came up with a new programming language today would probably not think twice about using “←” for assignment, which should eliminate the nasty ambiguity. But the heritage of the 300-baud teletype is still with us today and unlikely to go away anytime soon.

Yet more evidence for Wadler's law

renox — Fri, 29 Jun 2018 15:00:42 +0000

> To prevent assignment from being used in a context where a value is expected the result type of an assignment could simply be defined as void,

You're splitting hair, the different between a statement and a function which will return always void..

Yet more evidence for Wadler's law

nybble41 — Fri, 29 Jun 2018 14:38:11 +0000

> C's assignment operator being an expression instead of a function is viewed as a source of errors

The errors are not due to assignment being an expression rather than a statement. To prevent assignment from being used in a context where a value is expected the result type of an assignment could simply be defined as void, while still treating it as an expression. The real issue, though, is the similarity between '=' and '==' and the fact that '=' is commonly used in math and elsewhere to represent equality, not assignment. Simply changing the names to '=' for equality and something like ':=' for assignment would have eliminated the issue without any change in semantics.

Yet more evidence for Wadler's law

excors — Fri, 29 Jun 2018 13:25:37 +0000

Isn't that largely solved by modern compilers producing warnings in that case? (or in Java by making it a compile error, except in the unlikely case that the variable is a boolean). Personally I haven't seen it be a significantly common source of bugs, compared to the dozens of other ways that bugs can be introduced by small syntax errors, so it doesn't seem worth hobbling the whole language just for that.

Yet more evidence for Wadler's law

adobriyan — Fri, 29 Jun 2018 13:17:39 +0000

It is hard to typo SETF into EQ or =. But it is very easy to typo '==' into "=".

Python has different operators for bitwise and logical operations which C should copy (already copied with iso646.h except if you try to use them, men will stop shaking hands with you).

Yet more evidence for Wadler's law

renox — Fri, 29 Jun 2018 12:53:40 +0000

> Of course the real problem here is not the discussion but Python's broken language design. John McCarthy figured out in 1958 that the artifical separation of statements and expressions is completely unnecessary, and yet Van Rossum felt it necessary to make that mistake again 40 years later.

That's funny: C's assignment operator being an expression instead of a function is viewed as a source of errors: if (toto = FOO) instead of if (toto == FOO),
which creates ugly things like Yoda speak if (FOO == toto) or the non-standardized (but less ugly) "double parenthesis" pattern.

Yet more evidence for Wadler's law

HelloWorld — Thu, 28 Jun 2018 21:00:56 +0000

“
In any language design, the total time spent discussing
a feature in this list is proportional to two raised to
the power of its position.
0. Semantics
1. Syntax
2. Lexical syntax
3. Lexical syntax of comments
”

Of course the real problem here is not the discussion but Python's broken language design. John McCarthy figured out in 1958 that the artifical separation of statements and expressions is completely unnecessary, and yet Van Rossum felt it necessary to make that mistake again 40 years later.

PEP 572 and decision-making in Python

ewen — Sun, 24 Jun 2018 23:53:24 +0000

I do miss "assign and test for truthiness" at times in Python (especially re.match, and loops over functions returning content until EOF, etc), but also dislike the bugs this can introduce in C code. Reusing the exception handling / context manager syntax ("... FUNCTION_OUTPUT as VAR") seems like an ideal solution to both problems to me, as it's impossible to confuse with "oh, I meant to compare values", it's consistent with other Python syntax which helps readability, and it is still almost as concise as the other variations being suggested (:=, etc).

In addition the "... FUNCTION_OUTPUT as VAR" would also trivially allow treating that specific VAR as block scoped (eg, as it is implicitly is a context manager / exception handler) without surprising anyone that happened. As with other Python scoping, if the variable already existed earlier, it could update the outer scoped variable instead of creating a new block scoped one.

Good suggestion!

Ewen

PEP 572 and decision-making in Python

epa — Fri, 22 Jun 2018 21:34:21 +0000

All variables in python are references, so assigning 5 to x never changes a or b ever.

That's the doctrine -- but as I noted, the language is structured so that the question can't even arise. Perhaps a better example would be

a = 5
def foo():
    a = 6
    f = lambda x: a := 7
    return f
print(a)
f = foo()
print(a)
f(0)
print(a)

Inside the function foo() the first assignment a = 6 only affects a local variable a, not the outer one. But which a should be affected when you call f(0)? The one in the caller's scope or the one in scope where the lambda expression was declared?

PEP 572 and decision-making in Python

k8to — Fri, 22 Jun 2018 16:02:09 +0000

In this case, I use the while True, but i've used the generator helper in scenarios where the while True was awkward. I've gotten challenged on it as being too exotic/weird though. Maybe they were right?

PEP 572 and decision-making in Python

k8to — Fri, 22 Jun 2018 15:59:29 +0000

I don't see how this scenario is a question. All variables in python are references, so assigning 5 to x never changes a or b ever.

PEP 572 and decision-making in Python

gdiscry — Thu, 21 Jun 2018 16:45:39 +0000

You don't even have to implement a new function, it already exists:

with open(…) as f:
    for line in iter(f.readline, ''):
        …

PEP 572 and decision-making in Python

smurf — Thu, 21 Jun 2018 14:30:51 +0000

You can rewrite the readline example to use a for loop, with a small generator helper:

def as_loop(fn, *args):
    while True:
        res = fn(*args)
        if not res:
            return
        yield res
…
f = open(…)
for line in as_loop(f.readline):
    …

assuming that you're opposed to the trivial rewrite of

while True:
    line = f.readline()
    if not line:
        break
    …

which I personally prefer.

PEP 572 and decision-making in Python

epa — Thu, 21 Jun 2018 07:41:34 +0000

I think it's more than that: the division between expressions and statements runs deep in Python, and makes it different from languages like C, where there is not such a great difference between the two. For example take a list comprehension

a = 1
b = 2
[x+1 for x in a, b]

That works because x+1 is an expression. On the other hand, x=1 is a statement, so cannot appear there. That means you don't have to consider the semantics of how to assign to each list element, and whether a, b are lvalues or rvalues. Now, if an expression can also perform assignment (as in C), you could have

[x := 5 for x in a, b]

Should this modify the values of a and b in the local scope? Should it make temporary copies of these values, assign 5 to them, and then return them without modifying the originals? Or should it fail at run time with an error that a is not modifiable?

PEP 572 and decision-making in Python

k8to — Thu, 21 Jun 2018 06:33:47 +0000

If we must have inline assignments, this is at least consistent.

PEP 572 and decision-making in Python

marcH — Thu, 21 Jun 2018 05:10:25 +0000

> But Barry Warsaw believes that PEP 572 is an outlier. Since it changes the syntax of the language, people tend to focus on that without understanding the deeper semantic issues.

Would it have helped to decouple the two (or three, four...) questions and proceed in incremental stages? I mean discussing and voting incomplete-by-design PEPs like: 1. semantics; 2. syntax; 3. lex. Earlier PEPs could be approved even with abstract/incomplete content like for instance this:

if ( x :TBD= 5)

PEP 572 and decision-making in Python

em-bee — Thu, 21 Jun 2018 02:33:16 +0000

(with added exception handling)

PEP 572 and decision-making in Python

em-bee — Thu, 21 Jun 2018 02:23:52 +0000

or like this?

for i in [(p1,1),(p2,2),(p3,3)]:
    return re.match(i[0], line).group(i[1])

greetings, eMBee.

PEP 572 and decision-making in Python

IkeTo — Thu, 21 Jun 2018 01:01:24 +0000

I wonder why it cannot be made to be consistent with exception handling syntax and context manager syntax by using the "as" keyword. Like:

if re.match(p1, line) as m:
    return m.group(1)
elif re.match(p2, line) as m:
    return m.group(2)
elif re.match(p3, line) as m:
    ...

while f.readline() as line:
    ...  # process line

PEP 572 and decision-making in Python

dw — Thu, 21 Jun 2018 00:54:50 +0000

Not just added complication, but added incompatibility. The language has barely shifted in productivity since 2.3-2.5 era (of course this could be debated), yet maintaining compatibility with even 5 year old installs is nigh impossible given the continuous "feature" additions

PEP 572 and decision-making in Python

tbodt — Wed, 20 Jun 2018 21:01:53 +0000

The first example given could also be written like this:

m = re.match(p1, line)
if m:
    return m.group(1)
m = re.match(p2, line)
if m:
    return m.group(2)
m = re.match(p3, line)
if m:
    return m.group(3)
...

PEP 572 and decision-making in Python

k8to — Wed, 20 Jun 2018 18:59:44 +0000

It's another in a long line of python mistakes, making the language more complicated for very minor benefit.

If you want to handle pattern match better, then add a pattern match construction. That would have a lot of power, clarity and efficiency of expression. Inline assignments let you make a lot of things less explicit with very small gains in efficiency of representation, no matter how you spell them.