Was really hoping to see multi-core in 3.8, looks like we'll be waiting until 3.9
What's Coming in Python 3.8
101–110 of 558 posts
Re: What's Coming in Python 3.8
#102I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…
From what I've seen, Go is the closest we have for mainstream language resistant to change.
Re: What's Coming in Python 3.8
#103The title made me think "Be afraid. Be very afraid". But it's all little stuff. Unchecked type annotations remain the worst addition since 3.0. Actual typing might be useful; it allows optimizations and checking. But something that's mostly a comment isn't that helpful.
Both static checking and compilation can be implemented using third party libraries. I think projects like mypyc could be a real game-changer.
Re: What's Coming in Python 3.8
#104The lack of the "nursery" concept for asyncio really sucks. Originally I heard it was coming in 3.8. Right now asyncio has this horrible flaw where it's super easy to have errors within tasks pass silently. It's a pretty large foot gun.
You can code your own wrapper for this. Like https://github.com/Tygs/ayo It's not as good as having it in the stdlib, because people can still call ensure_future and not await it, but it's a huge improvement and completly compatible with any asyncio code.
Yup for sure. My complaint is part ergonomics of boilerplate, part this really burned me bad and no stdlib documentation warns you upfront about it. So many hours of headscratching.
Re: What's Coming in Python 3.8
#105Earlier quoted context omitted.
I don't know how you read it - 'if x is assigned the value y'? Most other things in Python can just be read out loud.
Read it "if y" - that's what's being tested. The walrus simultaneously names the value being tested so you can refer to it within the condition; it's sort of the inverse of Perl code using $_. So instead of if (do_something()) { act_on($_); } you have if placeholder := do_something(): act_on(placeholder) But when reading aloud, however you'd read the perl will flow as more natural english. "If the string contains z,…
>Read it "if y" - that's what's being tested.
Once way to test if this works is to take the code, read it aloud, and then use the read-aloud version to rewrite the code. If you don't have a high degree of certainty that you end up with the same code, something has failed along the way.
In this case, if I take "if x:= y()" and read it aloud as "if y", I think the vast majority of people would translate that to code as "if y():", which isn't the same thing.
Re: What's Coming in Python 3.8
#106Earlier quoted context omitted.
Regular = can only be used in statements. Walrus := can only be used in expressions. There's no overlap there. However, := does simplify certain expressions (like those nested if-else statements and the common "while chunk := read()" loop), which I think does justify its existence.
This honestly makes it seem more confusing to me. The fact that there is now an operator that can only be used in certain statements just makes things more confusing. And if there really is no overlap, then why wasn't the "=" operator just extended to also work in expressions? "while chunk = read()" seems like it makes just as much sense without adding the confusion of another operator.
One of the good things about not using the "=" operator is that you cannot accidentally turn a comparison into an assignment, a feature that is a common cause of errors in other languages that do support it. By adding a completely different character to the operator it is not very likely to cause bugs, compared to just forgetting to type that second =
Re: What's Coming in Python 3.8
#107Very much seems like perlification, and we all know what happened to Perl.
Although that being said I always really liked Perl
Re: What's Coming in Python 3.8
#108Wow. Never would I have guessed the amazing concept of assignment expression is so confusing for, what it seems, a lot of python programmers.
It really was time to introduce it to them.
Re: What's Coming in Python 3.8
#109Earlier quoted context omitted.
I see what you're saying, but I kinda like the gets ":=" operator.
But now there are two ways to do assignment. That's not very pythonic, is it?
There are at least three ways to iterate over a list and create a new list as a result. That's not very pythonic, is it?
Re: What's Coming in Python 3.8
#110The changes to f-strings just seems like a step in the wrong direction. Don't make the string content implicit!
Also, why abandon printf-style? All languages tend to converge to printf over time, it's simply the most tried and tested model out there!
javascript, python, rust, etc. don't use printf style, but instead use the {} style.