seeking deeper (language theory) reason behind Python design choice

[Peter J. Holzer]

On 2018-05-16 00:04:06 +0000, Steven D'Aprano wrote:
> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
> > On 2018-05-15 00:52:42 +0000, Steven D'Aprano wrote:
> [...]
> >> By 1991 there had already been *decades* of experience with C
> > 
> > About one and a half decades.
> 
> That would still be plural decades.
> 
> C's first release was 1972, so more like 19 years than 15.

I thought it was 1974, but Ritchie writes "By early 1973, the essentials
of modern C were complete." So you are closer than me. But we don't
know whether those early users of C tended to confuse “=” and “==”
(Ritchie did change the compound assignments from ”=+”, “=-” etc. so
“+=”, “-=”, etc., so at the early stages he did change syntax if it
proved to be error-prone. He didn't change the precedence of “&” and “|”
after introducing “&&” and “||”, though.). C spread beyond the Unix team
in the mid to late 70s.

> >> proving that the "=" assignment syntax is dangerously confusable with
> >> == and a total bug magnet when allowed as expressions as well, so it
> >> was perfectly reasonable to ban it from the language.
> > 
> > Experience? Yes. Data? I doubt it.
> 
> I'm using "proving" informally above, not in the sense of actual legal or 
> scientific standards of proof.

“Proof by assertion”? I am not a native English speaker, but I don't
think just claiming that something is the case constitutes a “proof”
even in the most informal use of the language.

Humans are notoriously bad at estimating risk. We often talk a lot about
and take rather extreme measures to avoid relatively small risks (e.g.
being killed in a terrorist attack) while mostly ignoring much larger
risks (e.g. being killed in a car accident). Yes, bugs of this class
were found in the wild. Yes, compiler writers added warnings about
suspicious use of assignments in a boolean context. Yes, Guido avoided
assignment expressions because he thought they were too dangerous. But
does any of this prove that assignment expressions are “a total bug
magnet”? I don't think so.


> If you are going to object to that, remember that neither is there 
> scientific data proving that assignment as an expression is useful, so we 
> can always just reject the construct as "useless until proven otherwise" 
> :-)

It is used, therefore it is useful ;-).

I think it is very useful in C which reports exceptional conditions
(errors, end of file, ...) by returning reserved values. So you often
want to combine an assignment and a test. The vast majority of
assignment sub-expressions you'll see in a C program are of this type.

I think it would be much less useful in Python, because Python has
exceptions and generators (and these are used by both the standard
library and idiomatic Python code). So most situations where you would
use an assignment sub-expression in C simply don't arise. As I said, I
don't miss the feature in Python.


> > I have been programming in C since the mid-80's [...]
> > I guess I could write a script which
> > searches through all my repositories for changesets where “=” was
> > replaced by “==”. Not sure what that would prove.)
> 
> You were using version control repositories in the 1980s, and still have 
> access to them? I'm impressed.

I started using Unix in early 1987 and SCCS shortly afterwards. So this
year may mark my 30th anniversary as a version control system user. But
I don't know if I still have any of my SCCS repos, and if I have, the
disks and tapes probably aren't readable any more.

But I wasn't actually thinking of going that far back. I am not much
interested whether I made that kind of error as a C newbie in 1987. I am
interested whether I made it as an experienced C and Perl programmer.
So I was thinking of analyzing repos which are moderately current. If I
could find cases where I wrote “=” instead of “==”, I'd have to admit
that a) I do make that error at least occationally and b) I don't always
find it before committing. But that still wouldn't prove anything: I
would have to compare it to other bug classes, and most importantly,
whether a single programmer (me) tends make (or not make) a specific
error doesn't say anything about the entirety of programmers. And it's
the latter that counts.


> > OTOH, despite having used C and Perl long before Python, I don't miss
> > assignment expressions. Every language has its idioms, and just because
> > you write stuff like “if ((fd = open(...)) == -1)” a lot in C doesn't
> > mean you have to be able to write that in Python.
> 
> I'm not a C coder, but I think that specific example would be immune to 
> the bug we are discussing, since (I think) you can't chain assignments in 
> C. Am I right?
> 
>     fd = open(...)) = -1
> 
> would be a syntax error.

Yes, because you omitted a parenthesis ;-), But yes, that would be error
(although not a syntax error - the syntax is fine), because the result
of an assignment isn't an l-value in standard C and cannot be assigned
to. Some compilers (among them GCC) offer that as an extension, though.

I used this example because it is very idiomatic C. Every C programmer
writes that dozens of times a day. But I don't feel the need to write
that in Python because Python has other (arguably more elegant)
mechanisms.

> But:
> 
>     fd = -1
> 
> would not be.

Yes. A C programmer might write “if (fd = -1)” instead of “if (fd == -1)”.
But I don't think that it happens all that frequently.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180519/015c6cfe/attachment.sig>