We would like to be able to introduce logical constructs to ppl using “and if” and “or if” syntax, instead of the traditional “and” and “or”.
Ultimately, we feel like “if x and if y” is slightly easier to explain than “if x and y” when x and y are function calls.
So, this tiny addition to the language would help us a lot with how we introduce ppl to this stuff!
and that is exactly the problem.
Who is “we”? What group of educators are you representing? Have you done any studies to confirm that this would indeed be easier? Are the students you have difficult explaining if x and y to already familiar with english?
Ultimately the chance of this syntax being added is very low:
if x and if y or if x and y? The latter is never going to get removed since that would break approximately all python code.x if a else y - it wouldn’t be ambiguous for the python parser, only for human parsers.the problem is the lazy evaluation of and/or. from observing on the internet, it always trips ppl up when they first encounter it.
we don’t have students. we have friends, colleagues, etc. knowledge should be shared, like memory, not passed on like file descriptors.
why do we even have the lazy shorthand anyway
It’s a very common programming language feature: Short-circuit evaluation - Wikipedia
It is easy enough to trigger eager evaluation in a language with short-circuiting; it is more cumbersome to go the other way.
I don’t know what Guido’s reasoning was, but it would be both controversial and massively breaking to change it now, so it’s safe to say that won’t happen.
it is, indeed. but even wikipedia recognizes the problems with it.
with references.
A block header such as if x and if y: seems unnecessarily wordy as compared to if x and y:, in both code and as a pattern for natural language sentences.
In anticipation of a cold rainy day, we might offer this advice:
If the weather is cold and rainy, wear a heavy raincoat.
That flows more naturally than this rephrasing:
If the weather is cold and if the weather is rainy, wear a heavy raincoat.
Admittedly, preferred phrasing of prose might vary geographically, culturally, and among different natural languages, as well as how that transfers to preferred syntax for programming code.
To add new syntax options to Python, we need a really good reason, and this does not seem the occasion for doing that.
alternatively, we would be happy to see block melding:
if x:
if y:
pass
# else: # SyntaxError: ambiguous else
(because block melding is cool. but anyway.)
we just don’t think lazy expressions are a good idea in the real world. they cause bugs. they should be discouraged. we should have alternatives that are more obvious.
These are fundamental language design decisions, and a language over 30 years old is unlikely to change them.
Saying “if the weather is cold and if the weather is rainy, wear a heavy raincoat” can be interpreted as “if the weather is cold, and also if the weather is rainy, wear a heavy raincoat”, which means “if the weather is cold or rainy, wear a heavy raincoat”. That’s not the same as “if the weather is cold and rainy, wear a heavy raincoat”.
You get that kind of thing in C, C#, and other languages, in the switch statement, except that the case falls through to the next case, which is like having case x or y. or, not and.
so is memory safety.
and yet even clang is (slowly) adding -fbounds-safety.
these things can change. and, more often than they do, they should change. just because we’ve been doing something for over 30 years (e.g. writing memory-unsafe code) doesn’t mean we should keep doing it.
nah, block melding is about de-indenting immediately nested blocks.
previously:
if x:
for v in x:
pass
after block melding:
if x:
for v in x:
pass
way cleaner too.
Who is the “we” that you keep referring to? Anybody other than you?
Unsafe memory is a constant pain point with catastrophic results. Short-circuiting is not. Not even close.
True.
Without shortcircuiting, this:
while index < len(haystack) and haystack[index] == needle:
raises an exception if it reaches the end.
Languages that don’t shortcircuit and and or are annoying.
Soni is referring to themselves: https://morethanone.info/
but we don’t need short-circuiting expressions for this.
we just need to come up with a good alternative. something using statements instead.
An alternative to something that already works?