Sure, there is a difference between '==' becoming '=', and '=='
Oh come on, you're grasping at straws. What about the difference
between '>' and '<'? Those are even closer together than ':' and '='.
Do you want to get rid of those operations too? The '=' vs '==' thing
may actually confuse some people but it's hard to mistake := for
anything other than an assignment.
Who said anything about confusing them? I merely stated that it would
be relatively easy to mistype. If what you are proposing is used, and
people actually try converting their old-style-while to new-style-while,
it would be easy to forget to insert the colon. When writing new loops,
it would also be relatively easy to slip and insert a := when intending
==. Looking at my keyboard, := rather than >= would be even more likely
(or even the reverse), because one already has the shift-key down, and
the keys are adjacent to one another.
You can say that I am grasping at straws, but ignoring mistyping as a
source for bugs, is foolish on your part.
That's sheer speculation on your part. You've cited the existence of
assignment expression errors causing 'more than one bug' in the
hundreds of millions of C code written over the past three decades.
I didn't offer more because I've never used the syntax in my C/C++ code,
nor have I waded through millions of lines of C. I also wouldn't want
to go through the potentially thousands of lines where it is used. That
would be a waste of time.
That's not persuasive of anything, given how many other bugs there are
of just about every other sort.
A better statement would have been, "That says nothing about the
proportion of bugs in such assignments, as compared with other
syntactical bugs." Which would be correct. But as I just said, I
haven't waded through millions of lines of C and categorized the types
of syntax bugs. Certainly it is speculation on my part, but it is
conservative speculation.
All proposed methods that ask to change syntax, deviates from Python
style, which /may/ introduce more bugs.
And in fact, the one in the Linux
kernel shows the opposite of what you're claiming. It wasn't an
accidental error that slipped through anything; it was a deliberate
hole that someone introduced hoping no one would notice, but it was
noticed immediately, showing that the =/== distinction is less
difficult to spot than you seem to think.
I never claimed it was difficult to spot. I claimed it was easy to make
such a typing mistake. Certainly the exploit was deliberate, but had
the linux kernel not been as well audited as it is, the bug may have
persisted. In the few thousand lines of C code I wrote during
undergrad, I know I made a handful of == -> = typing errors. I expect
that the occasional slip from one to the other is not uncommon.
Assignment expressions have been used successfully in C and other
languages for many years, including plenty of them in the CPython
code. It's reasonable to say they're used all the time by some very
capable programmers and it's impertinent of you to imply that those
programmers don't know what they're doing.
You seem to like to put words into people's mouths. I never said that C
programmers don't know what they are doing when they are using them. I
said that it would be easy to mistype, and seeks to solve a "problem" in
Python that isn't one.
If you don't like them,
fine, don't use them, but don't try to convince people who use them
that they're wrong.
What people do with other langauges, I do not concern myself with. If
you want to use while (a = b) in other languages, feel free. On the
other hand, when you talk about taking a language that I care about,
that I use on a daily basis for both work and play, and mangle it with
what I consider to be useless syntax, I (and everyone else I expect)
reserve the right to give my opinion. I never said that its use in
other languages was wrong, just that I don't want it in Python. Which
leads me to:
I think PEP 315 is a waste of bits. In my opinion, Python doesn't need
a syntax change for while loops, and those who cannot understand the
flow of:
while 1:
#setup
if <condition to stop>: break
#loop internals
Are operating on a lower conceptual level than the majority of CS
undergrads that I teach on a daily basis at UC Irvine. Now, UCI is a
decent school, so maybe we are setting the bar too high. However, the
above while loop is clearer (even though it is more verbose), than all
of the suggested syntax changes.
What's a programming language like Python aiming
to do, anyway? Among other things, it aims to make programming
non-frustrating. So if a sizeable population of users find that the
absence of a particular useful feature is actually frustrating, give
some thought to the idea that the absence really is a shortcoming in
the language.
I did give some thought to it. I think the bugs that may occur as a
result of its availability would be far more frustrating than the
relatively minor additional typing required for old-style loops.
- Josiah
