if any(len(longline := line) >= 100 for line in lines):
print("Extremely long line:", longline)
Old way:
for line in lines:
if len(line) >= 100:
print("Extremely long line:", line)
break
I prefer the old way. These were examples in the PEP!
In your example get_it() might be better as a generator or iterable. A lot of code looks great if you push that type of thing down a bit, and sometimes memory is helped as well. Then you iterate over it, for values in get_it. This keeps python very natural. You start to get a lot of weird line noise type code with := vs the old python style which while a bit longer was basically psudo-code.
I still don't see the need for things like the walrus-operator.
All it does is increase line-noise, and for what? So we don't have to write 2 short lines, or save an indentation level somewhere?
There is a good reason why assignments in Golang are not expressions, even though they are in C, and the language is otherwise deliberately close to the mindset of C; The added convenience makes the code much harder to read.
char c;
while(1) {
c = getch();
if (c == EOF)
break;
// do something
}
but it's also easier to read, because each line carries less information. That's what people call "line noise".
IMO, := is a step in the wrong direction, and sadly I see python take more and more of these, going from the deliberately simple and clear language to something that's becoming needlessly hard to read by piling on things it doesn't even need.
ie, instead of
for line in lines: print(line)
we are supposed to be using
while line := f.readline(): print(line)
I've not been super impressed with this type of thing.
That said, string formatting is better with f strings.
They also rolled back some the forced breakage from trying to force unicode with 3 which made a big difference. 3.3 added back u''
Lots of good cleanups lstrip vs removeprefix etc.
Underscores in numeric literals (10000000 vs 10_000_000)
So lots of good stuff still landing.