What's Coming in Python 3.8

Despite controversy, walrus operator is going to be like f-strings. Before: &quot;Why do we need another way to...&quot; After: &quot;Hey this is great&quot;.<p>People are wtf-ing a bit about the positional-only parameters, but I view that as just a consistency change. It&#x27;s a way to write in pure Python something that was previously only possible to say using the C api.

Python looks more and more foreign with each release. I&#x27;m not sure what happened after 3.3 but it seems like the whole philosophy of &quot;pythonic&quot;, emphasizing simplicity, readability and &quot;only one straightforward way to do it&quot; is rapidly disappearing.

To me, the headline feature for Python 3.8 is shared memory for multiprocessing (contributed by Davin Potts).<p>Some kinds of data can be passed back and forth between processes with near zero overhead (no pickling, sockets, or unpickling).<p>This significantly improves Python&#x27;s story for taking advantage of multiple cores.

I long for a language which has a basic featureset, and then &quot;freezes&quot;, and no longer adds any more language features.<p>You may continue working on the standard library, optimizing, etc. Just no new language features.<p>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 <i>any</i> code.<p>If new language features get added over time, eventually you get to the case where there are obscure features everyone has to look up every time they use them.

Speaking as someone who has written Python code almost every day for the last 16 years of my life: I&#x27;m not happy about this.<p>Some of this stuff seems to me like it&#x27;s opening the doors for some antipatterns that I&#x27;m consistently frustrated about when working with Perl code (that I didn&#x27;t write myself). I had always been quite happy about the fact that Python didn&#x27;t have language features to blur the lines between what&#x27;s code vs what&#x27;s string literals and what&#x27;s a statement vs what&#x27;s an expression.

There&#x27;s a lot of talk in this thread about Python going down-hill and becoming less obvious&#x2F;simple. I rather like modern python, but I agree that some features (like async&#x2F;await, whose implementation fractures functions and libraries into two colors [0]) seem like downgrades in &quot;Pythonicity&quot;.<p>That said, I think some things have unquestionably gotten more &quot;Pythonic&quot; with time, and the := operator is one of those. In contrast, this early Python feature (mentioned in an article [1] linked in the main one) strikes me as almost comically unfriendly to new programmers:<p>&gt; Python vowed to solve [the problem of accidentally assigning instead of comparing variables] in a different way. The original Python had a single &quot;=&quot; for both assignment and equality testing, as Tim Peters recently reminded him, but it used a different syntactic distinction to ensure that the C problem could not occur.<p>If you&#x27;re just learning to program and <i>know nothing</i> about the distinction between an expression and a statement, this is about as confusing as shell expansion (another context-dependent syntax). It&#x27;s <i>way</i> too clever to be Pythonic. The new syntax, though it adds an extra symbol to learn, is at least 100% explicit.<p>I&#x27;ll add that := fixes something I <i>truly hate</i>: the lack of `do until` in Python, which strikes me as deeply un-Pythonic. Am I supposed to break out of `while True`? Am I supposed to set the variable before <i>and</i> at the tail of the loop (a great way to add subtle typos that will cause errors)? I think it also introduces a slippery slope to be encouraged to repeat yourself: if assigning the loop variable happens twice, you might decide to do something funny the 2:Nth time to avoid writing another loop, and that subtlety in loop variable assignment can be very easy to miss when reading code. There is no general solution I&#x27;ve seen to this prior to :=. Now, you can write something like `while line := f.readline()` and avoid repetition. I&#x27;m very happy to see this.<p>[0] <a href="https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-...</a><p>[1] <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;757713&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;757713&#x2F;</a><p>[edit] fixed typos

Was really hoping to see multi-core in 3.8, looks like we&#x27;ll be waiting until 3.9<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0554&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0554&#x2F;</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;ericsnowcurrently&#x2F;multi-core-python&#x2F;wiki" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ericsnowcurrently&#x2F;multi-core-python&#x2F;wiki</a>

Without wanting to ignite a debate about the walrus operator (and having not read any of the arguments), I can guess why there was one. It&#x27;s not clear to me what it does just from reading it, which was always one of Python&#x27;s beginner-friendlinesses.

Walrus operator looks like a great addition, not too much syntax sugar for a common pattern. Why were folks arguing about it?

<a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3.8&#x2F;whatsnew&#x2F;3.8.html" rel="nofollow">https:&#x2F;&#x2F;docs.python.org&#x2F;3.8&#x2F;whatsnew&#x2F;3.8.html</a>

Very much looking forward to assignment expressions! It&#x27;s something I&#x27;ve wanted to do every so often, only to realise that you can&#x27;t. A worthy addition to the already intuitive Python language.

Have there been any performance benchmarks done on Python 3.8 yet? I&#x27;d be interested in seeing how it compares to 3.6 and 3.7, but haven&#x27;t seen anything published.

Anyone else think the walrus operator is just plain ugly? There is a certain aesthetic quality that I&#x27;ve always appreciated about the Python language and the walrus operator looks like something straight out of Perl or Shell.

I recommend a talk from Pycon 2019, wherein Dustin Ingram explains PEP-572 (aka the Walrus Operator) better than I’ve seen done elsewhere.<p>IMHO, the usefulness of this new operator outweighs the slight learning curve required to get past the awkwardness you will experience when you are first acquainted to it.<p>Here is that talk:<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;6uAvHOKofws" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;6uAvHOKofws</a>

Also type hints for dictionaries with fixed keys:<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0589&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0589&#x2F;</a><p>I know it&#x27;s almost always better to use objects for this, but tons of code still uses dictionaries as pseudo-objects. This should make bug hunting a lot easier.

Gotta ask how many of these changes are actually reflective of changing environments.<p>I could see with c++ that between 2003 and 2014 a fair few underlying machine things were changing and that needed addressing in the language.<p>But Python is not quite as close to the machine, and I don&#x27;t see how something like the walrus is helping much. If anything it seems like you&#x27;d scratch your head when you came across it. And for me at least one of the main attractions of python is you&#x27;re hardly ever surprised by anything, things that are there do what you guessed, even if you hadn&#x27;t heard of them. Function decorators for instance, you might never have seen one but when you did you knew what it was for.<p>Same with the debug strings. That seems to be a special case of printing a string, why not leave it at that? I&#x27;m guessing a lot of people don&#x27;t ever read a comprehensive python guide, what are they going to do when they see that?

It seems like the PEP0505 for None aware operator is delayed indefinitely.<p>It would be great if there was more momentum on this again, as it would be helpful in all sorts of places.<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0505&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0505&#x2F;</a>

The lack of the &quot;nursery&quot; concept for asyncio really sucks. Originally I heard it was coming in 3.8. Right now asyncio has this horrible flaw where it&#x27;s super easy to have errors within tasks pass silently. It&#x27;s a pretty large foot gun.

&quot;:=&quot; is a fairly common operator symbol that I&#x27;ve seen used in other programming languages (e.g. Golang) and in mathematics. But I&#x27;ve never seen it called the &quot;walrus&quot; operator. Its fitting and memorable though, I like it.

The problem with modern Python is that it&#x27;s trying to recreate C# or Java. Which leaves it with nothing, because it&#x27;ll only end up an inferior version of the languages&#x2F;platforms of which it&#x27;s attempting to duplicate.<p>When I was into Python, I liked it because it was a tighter, more to the basics language. Not having 4 ways to format strings and so forth. I don&#x27;t think Python can defeat Java by becoming Java. It&#x27;ll lose there due to multiple disadvantages. The way Python &quot;wins&quot; (as much as it could at least), is focusing on &quot;less is more&quot;. They abandoned that a while ago.<p>My vision of a language like Python would be only 1-way to do things, and in the event someone wants to add a 2nd way, a vote is taken. The syntax is changed, and the old bytecode interpreter handles old scripts, and scripts written with the latest interpreter&#x27;s bytecode only allows the new syntax. For me that&#x27;s the joy of Python.<p>I think a lot of people wanted Python&#x27;s original vision, &quot;one way to do things&quot;. If I want feature soup, I&#x27;ll use what I program in daily. Which I do want feature soup by the way, I just have no need to replace it with another &quot;feature soup&quot; language like Python turned into because it&#x27;s inferior on technical and for me, stylistic levels.

I find the different philosophies of languages amazing.<p>Just recently &#x27;Declined Proposal: A built-in Go error check function, “try”&#x27; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20454966" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20454966</a> made the front page, explaining how a controversial potential Go feature was being declined early.<p>Python on the other hand, went ahead with what seems to be a proposal at least as controversial as &#x27;try&#x27; in Go.

I noticed some changes to pickle; do people still use pickle for Real Work?<p>Potential vulnerabilities aside, I got bitten by some migration issue back in the 2.2 to 2.4 transition where some built-in types changed how they did their __setstate__ and __getstate__ (iirc) and that caused objects picked under 2.4 to not unpickle correctly under 2.2 or something like that. After that I never wanted to use pickle in production again.

I feel like I&#x27;ve been seeing a lot of these almost identical articles pop up all over. Walrus operator, f-string equals, positional-only arguments, <i>yawn</i>. None of that is really going to change your life.<p>There&#x27;s a bunch of changes in the official &quot;what&#x27;s new&quot; doc that I think are more interesting:<p><a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3.8&#x2F;whatsnew&#x2F;3.8.html" rel="nofollow">https:&#x2F;&#x2F;docs.python.org&#x2F;3.8&#x2F;whatsnew&#x2F;3.8.html</a><p>* Run-time audit hooks, to see if your modules are making network requests, etc.<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0578&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0578&#x2F;</a><p><a href="https:&#x2F;&#x2F;tirkarthi.github.io&#x2F;programming&#x2F;2019&#x2F;05&#x2F;23&#x2F;pep-578-overview.html" rel="nofollow">https:&#x2F;&#x2F;tirkarthi.github.io&#x2F;programming&#x2F;2019&#x2F;05&#x2F;23&#x2F;pep-578-o...</a><p>* multiprocessing SharedMemory for fast data sharing between processes<p><a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3.8&#x2F;library&#x2F;multiprocessing.shared_memory.html" rel="nofollow">https:&#x2F;&#x2F;docs.python.org&#x2F;3.8&#x2F;library&#x2F;multiprocessing.shared_m...</a><p>* Duck-typing for the static annotation checkers<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0544&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0544&#x2F;</a><p>* Literal checking for the static annotation checkers. ie: It&#x27;s not enough to check that you&#x27;re passing a string for the mode in open(), you want to check that it&#x27;s &#x27;r&#x27; or &#x27;w&#x27;, etc.<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0586&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0586&#x2F;</a><p>* The compiler now produces a SyntaxWarning when identity checks (is and is not) are used with certain types of literals (e.g. strings, ints). These can often work by accident in CPython, but are not guaranteed by the language spec. The warning advises users to use equality tests (== and !=) instead.<p>* A bunch of speed and memory optimizations:<p>- &quot;Sped-up field lookups in collections.namedtuple(). They are now more than two times faster, making them the fastest form of instance variable lookup in Python.&quot;<p>- &quot;The list constructor does not overallocate the internal item buffer if the input iterable has a known length (the input implements __len__). This makes the created list 12% smaller on average.&quot;<p>- &quot;Doubled the speed of class variable writes.&quot;<p>- &quot;Reduced an overhead of converting arguments passed to many builtin functions and methods. This sped up calling some simple builtin functions and methods up to 20–50%.&quot;

I&#x27;m all in favor of the walrus operator for the for loop, but the first example given to justify it is code I&#x27;d never write. The first if does a return, so there is no need for the else: and indentation. I&#x27;m sure there are other code examples that would justify it, but this one is unconvincing.

The title made me think &quot;Be afraid. Be very afraid&quot;. But it&#x27;s all little stuff.<p>Unchecked type annotations remain the worst addition since 3.0. Actual typing might be useful; it allows optimizations and checking. But something that&#x27;s mostly a comment isn&#x27;t that helpful.

&gt;Python 3.8 programmers will be able to do: print(f&#x27;{foo=} {bar=}&#x27;)<p>Ugh, how did this get approved? It&#x27;s such a bizarre use case, and debugging by print should be discouraged anyway. Why not something like debug_print(foo, bar) instead (because foo and bar are real variables, not strings)?

At first, after reading the comments and before reading the article, I thought everyone was just casually bashing because of change. But just look at this :<p>def fun(a, b, &#x2F;, c, d, *, e, f):<p>or<p>print(f&#x27;{now=} {now=!s}&#x27;)<p>and guess what it does before actually reading the article.<p>Worst, the rationales of the PEPs are weak, presenting improvement for &quot;performances&quot; or enforcement of API because of low level stuff as C.<p>Back when I was 18 years old, Python was high level, rules were simple with only one way of doing things and performances weren&#x27;t a concern, because you would just use the right language for the right task. There was no enforcement and you could always hack a library to your liking. Python now is getting closer to what Perl looked to me 10 years ago, trying to optimize stuff it shouldn&#x27;t

Does anyone know the status of pep-582 : <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0582&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0582&#x2F;</a><p>It&#x27;s still marked as a 3.8 target

I feel like walrus operators, while a cool construct, are at odds with &quot;The Zen of Python&quot;.<p>Specifically &quot;There should be one -- and preferably only one --obvious way to do it.&quot;<p>If this was any other language, the addition would be welcome, but I feel that the walrus operator fundamentally disagrees with what python is about.<p>It&#x27;s not about terseness and cleverness, it&#x27;s about being clear, and having one way to do things (Unless you are Dutch).<p><a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0020&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0020&#x2F;</a>

I believe that I hit places where I&#x27;d use the walrus about once every few hundred lines of python, so I do see a use for it. OTOH I am worried that it makes the language harder to understand for beginners, and that is a very important role Python plays in the world of programming languages.<p>The abbreviated f-string syntax looks weird and kinda wrong to me. But then I&#x27;m not even sure I&#x27;ve got comfortable yet with the object field initialization shortcuts in Javascript and Rust (where you also get to omit stuff to avoid repeating yourself).

&gt;Debug support for f-strings.<p>F strings are pretty awesome. I’m coming from JavaScript and partially java background. JavaScript’s string concatenation can become too complex and I have difficulty with large strings.<p>&gt;Python 3.8 programmers will be able to do: print(f&#x27;{foo=} {bar=}&#x27;)<p>Pretty cool way to help with debugging. There are so many times, including today, I need to print or log some debug string.<p>“Debug var1 ” + var1 + “ debug var2” + var2...and so on. Forgot a space again.

Is there anything similar to BabelJS for Python? Now after 3.8 I start to feel there are a need for a tool like that.<p>More compact code at the cost of higher learning curve.

Its kind of amazing to me switching from PHP&#x2F;Ruby to Python, that things like f strings and walrus operators are just now being added to python.

The walrus operator does not feel like Python to me. I&#x27;m not a big fan of these types of one liner statements where one line is doing more than one thing.<p>It violates the philosophies of Python and UNIX where one function, or one line, should preferably only do one thing, and do it well.<p>I get the idea behind the :=, but I do think it&#x27;s an unnecessary addition to Python.

The changes to f-strings just seems like a step in the wrong direction. Don&#x27;t make the string content implicit!

Python has &quot;jumped the shark&quot; for me. Python is no longer Pythonic (the &quot;import this&quot;, zen of python easter egg should be removed). It&#x27;s lost it way and is TIMTOWTDI now, heading for that Perl 6 brass ring. Golang is now the Pythonic language.

I&#x27;ll just put a reminder here that it&#x27;s the year 2019 and AMD and Intel has 10-core CPUs while Python is still stuck with GIL ¯\_(ツ)_&#x2F;¯

I love the f-strings and the new enhancements, but I&#x27;m still skeptical about the walrus operator and the positional argument change.

Does it make sense to use := everywhere (can it be used everywhere?) instead of just in conditionals? Just like Pascal.

Do parsers of previous pythons emit warnings: &quot;this feature is not available in pythons 3.3 3.4 3.5 etc&quot; ?

That walrus operator has given me exactly what I wanted from C. Although I&#x27;d have preferred:<p>if val = expr():

How come they are using a new := operator instead of using equals?

What Python needs is a better lambda syntax similar to JS and true anonymous multiline functions. Defining and using lambdas in Python feels very unpythonic, this is something JS gets perfectly.<p>Also fix the GIL.

Isn&#x27;t the walrus just like a case statement?

All I care about is allowing a print statement in addition to the print function. There&#x27;s no technical reason why both can&#x27;t coexist in a perfectly usable manner.

I dont like the positional only arguments..<p>Really, I dont like anything that trys to force a future developer into using your code the way you expect them to.

No new way to format a string?

Very much seems like perlification, and we all know what happened to Perl.<p>Although that being said I always really liked Perl

And the GIL...

2nd 2

3r

3

tl;dr: Computation is being compressed ever more

Personally, I vote against the walrus. Code complication for a limited set of use cases. Boo, bad walrus.

Why elif en not juste elseif?