Software-update: Python 3.9.0

Python is een objectgeoriënteerde programmeertaal die kan worden gebruikt om eenvoudige tot complexe, platformonafhankelijke applicaties te ontwikkelen. Het is in de jaren negentig ontworpen door Guido van Rossum, die destijds in Amsterdam voor het CWI werkte. Guido, die als BDFL betrokken was bij de ontwikkeling van Python en tevens voor Dropbox heeft gewerkt, is inmiddels met pensioen. Het ontwikkelteam heeft versies 3.9.0 van Python uitgegeven en de belangrijkste verbeteringen die daarin zijn aangebracht zijn hieronder voor je op een rijtje gezet:

Some of the new major new features and changes in Python 3.9 are:

• PEP 573, Module State Access from C Extension Methods
• PEP 584, Union Operators in dict
• PEP 585, Type Hinting Generics In Standard Collections
• PEP 593, Flexible function and variable annotations
• PEP 602, Python adopts a stable annual release cadence
• PEP 614, Relaxing Grammar Restrictions On Decorators
• PEP 615, Support for the IANA Time Zone Database in the Standard Library
• PEP 616, String methods to remove prefixes and suffixes
• PEP 617, New PEG parser for CPython
• BPO 38379, garbage collection does not block on resurrected objects;
• BPO 38692, os.pidfd_open added that allows process management without races and signals;
• BPO 39926, Unicode support updated to version 13.0.0;
• BPO 1635741, when Python is initialized multiple times in the same process, it does not leak memory anymore;
• A number of Python builtins (range, tuple, set, frozenset, list, dict) are now sped up using PEP 590 vectorcall;
• A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, resource, time, _weakref) now use multiphase initialization as defined by PEP 489;
• A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384.

Versienummer	3.9.0
Releasestatus	Final
Besturingssystemen	Linux, BSD, macOS, Solaris, UNIX, iOS, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019
Website	Python
Download	https://www.python.org/downloads/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (36)

[Power2All]

Van Rossum geeft precies aan waarom ik van Python naar GoLang ben overgestapt: performance. CPython was extreem traag, als je het vergeleek met GoLang. Toegegeven, GoLang heeft ook een betere syntax dan python. Heb Python heel lang fijn gevonden, maar je merkte toch best wel snel de mankementen ermee.

[Yarisken]

Ik gebruik python voor vnl webscraping. Is het grote voordeel van python niet het grote aantal libraries ? Mis je dit niet in golang ?

[Power2All]

Nee, ik heb alle libraries in GoLang die ik ook met CPython (PyPy) ook had.
Probleem met Python, is dat het slecht met multi-core threading om kan gaan, vanwege GIL.
GoLang heeft daar uberhaupt geen last van.
Vooral met lang en stabiel draaiende activiteiten is GoLang extreem snel.
Heb een mini webserver draaiende die 300 connecties per seconden behandeld, zonder veel CPU gebruik.
Met Python was de CPU toren hoog, en werd er maar 1 core utilized.

[Overv]

Het hangt er wel net vanaf wat je doet. Zo draai ik een authenticatieserver met PostgreSQL die in Python geschreven is met behulp van asyncio en die handelt makkelijk 500 verzoeken per seconde af, waarbij het grootste deel van de tijd op I/O gewacht wordt met weinig CPU usage.

[Power2All]

CPython is kwa performance nog steeds de trage variant.
Probeer maar eens multi-threaded connecties te behandelen met Apache Benchmark bijvoorbeeld.
Dan zul je zien dat CPython toch echt begint af te haken op bepaalde momenten, waar GoLang vrolijk door stampt (getest met PyTornado)
Daarnaast, zoals ik al zei, omdat Python niet echt goed werkt met geheugen sharing (GIL), doet GoLang daar het beter mee, alleen GoLang's garbage collector moet nog verbetered worden.

[Reactie gewijzigd door Power2All op 24 juli 2024 05:22]

[The Third Man]

Je mist wellicht het punt dat met asyncio ook het concept met de GIL niet speelt. Door alleen maar te blijven hameren op multithreading performance blijf je zelf een beetje in 2014 hangen.

[Power2All]

Incorrect.
GIL is nog steeds aanwezig met asyncio.
Als je met geheugen bezig bent in Python, wordt het nog steeds door middel van locking traag.
Dit ivm dat er activiteiten in het geheugen door 1 thread uitgevoerd kan worden, voordat een andere thread het kan.
Deze context switching is juist inefficient in python.

[The Third Man]

Dan snap je denk ik toch niet hoe asyncio werkt. Een asyncio workflow is per definitie single threaded en dus vrij van context switching. De inefficientie van de multithreading vanwege de GIL speelt daar dus geen rol, want er is geen sprake van meerdere runnable threads. Het idee van asyncio is juist dat de main thread dynamisch van flow wisselt, en die dynamiek is geimplementeerd in de code zelf (door middel van await e.d.). Je hebt dus ook geen emperische switching meer die onhandig (en dus inefficient) kan plaatsvinden, de applicatie regelt de switching wanneer het uitkomt.

[Reactie gewijzigd door The Third Man op 24 juli 2024 05:22]

[Power2All]

Ik snap hem wel, maar GIL is nog steeds aanwezig en impact nog steeds je code.
Er zijn Python varianten waar GIL helemaal uit gesloopt is, en daar zie je dat de performance wat optimaler is.
In iedergeval, ik heb ook testjes met asyncio gedaan met CPython, PyPy, en PyPy werkt toch het optimaalst, maar zoals ik al eens eerder heb aangegeven, GoLang werkt voorals nog meer performant dan CPython. Er zijn hier ook heel veel discussies over gaande op Reddit:
https://www.reddit.com/r/...s/8kzxm5/gil_and_asyncio/

Is misschien ook interessante leesvoer voor je

[berchtold]

Probeer Rust. Geen garbage collector. Memory safe. Snel

[Power2All]

Heb ik al eens naar gekeken.
Rust is een leuke taal, maar kwa performance is het toch ietsje trager dan GoLang, en dat merk je vooral bij het scalen dat GoLang, Rust achterlaat.

[berchtold]

Dan vraag ik me af waar je deze info vandaan hebt of wat je zelf hebt gedaan. Maar Rust hoort sneller te zijn dan Go.

[Power2All]

Je hebt gelijk, had wat benchmarks verkeerd bekeken.
Maar, er wordt wel aangegeven dat GoLang in de latere processen als het komt op threading, het beter doet dan Rust, dit omdat GoLang van de grond was gebouwd om multi-threaded te zijn. Dit is later in Rust in gebouwd met async/await, maar het schrijven ervan vergt ervaring, waar dat bij GoLang redelijk tot best wel simpel is gedaan.

[berchtold]

Rust is ook goed in multi threading. Het mooie is ook dat bijna alles threadsafe is. Daar heb je niet per se async await voor nodig. Het is waar dat Rust meer ervaring vereist om goed te kunnen schrijven. Learning curve is erg steil. Maar zodra je het kan zul je altijd code schrijven die los van logica fouten altijd zal werken. De compiler van Rust is samen met het hele ecosysteem het meest krachtige wat ik ooit heb gezien in programmeertalen.

[berchtold]

Btw. Zie dat Go green threads gebruikt. Is geen native threading. Rust heeft wel native OS threads. Het lijkt me daarom dat Rust daar ook meer performant in is. Misschien is het in Go wel iets makkelijker te gebruiken.

Edit:
Hier zijn btw goeie benchmarks te vinden,
https://benchmarksgame-te...game/fastest/rust-go.html

[Reactie gewijzigd door berchtold op 24 juli 2024 05:22]

[Yarisken]

Ja bedankt voor je uitleg. Uit wat vergelijkingen haal ik dat als je met data bezig bent, gebruik python. Ben je met servers en processing bezig, gebruik GO.
Voor mij is het voordeel wel dat je alle dependencies mee kan compilen met GO.
Voor mij is python , waarvoor ik het gebruik, wel ideaal, vnl data scraping.

[Power2All]

Ik doe ook aan web scraping.
Dit gaat nog steeds sneller met GoLang dan met Python (dmv benchmarking).
Werk voor een bedrijf die ook aan ONIX parsing doet (CB API, een XML implementatie), die is er voor PHP, Python en GoLang.
Die van GoLang parsed toch echt bijna de helft sneller dan Python.
Ik moet toegeven, PHP7 gaat ook best wel de goede kant op kwa performance, maar Python en GoLang zullen nog altijd sneller zijn kwa parsing.

[Reactie gewijzigd door Power2All op 24 juli 2024 05:22]

[Robby517]

Ik weet niet waar je naar verwijst want Van Rossum is niet weggegaan van de BDFL positie bij Python omwille van de performance. Maar eerder door een zoveelste lange discussie over een PEP waar hij vond dat er te veel energie in kroop. Daarbij is het 'weggaan van' 1 taal voor een andere een beetje een vreemde uitspraak. Je kiest een taal/toolkit/etc best naargelang het probleem. De performance van Python is best goed als je er geen multithreaded zaken van verwacht want daar wringt het schoentje bij Python, de GIL.

[Reactie gewijzigd door Robby517 op 24 juli 2024 05:22]

[Power2All]

Klopt.
Maar als je de video omtrent van Rossum kijkt, zegt ie ook heel duidelijk dat hij niet gefocused was op performance voor Python, maar op simplicity, en dat is waar ik daar naar doelde.

[thePiett]

Een "betere syntax" is nogal subjectief denk ik

[Power2All]

Met Python, werkt door middel van tabs.
Als je een block wilt out-commenten, is dat een draak.
Bij programmeer talen zoals PHP, C, GoLang kan dat veel makkelijker (2 lijntjes is voldoende).
Daarnaast, omdat je lines breakt met de ; is het syntax ook duidelijker.
Dat mis ik soms wel bij Python.

[Guus...]

Om een block te outcommenten kan je tegenwoordig in de editor vaak met selecteren en een keyboard shortcut zonder moeite dit voor elkaar krijgen.
De syntax voor python is juist duidelijker. Tekens toevoegen die geen functie hebben leidt af en maakt de kans op syntax errors groter. Practisch in elke taal worden tabs gebruikt om de code leesbaar te maken dus is het overbodig om haakjes te gebruiken. Het einde van een regel valt bijna altijd samen met een enter dus dat is ook onzinnig om 2 keer aan te geven. Er zijn vast voorbeelden te bedenken waarbij dit niet zo is maar bij die voorbeelden is er ook een mouw aan te passen. Dat is beter dan overal in de code haakjes en punt-komma's te moeten plaatsen.
Wat betreft snelheid zijn er zeker betere talen maar voor veel toepassingen is de snelheid goed genoeg. Alleen wanneer je daar problemen mee verwacht is het verstandig om te optimaliseren.

[Power2All]

Het is wat je fijn vind.
Als je 3rd party apps nodig hebt om out te commenten (je moet elke regel out-commenten), dan dat je een /* en */ kan gebruiken en dat voldoende is, vind ik wel een zeer groot verschil.
Het probleem met Python meestal is ook, als je ergens een spatie te weinig of teveel in een lijn hebt, breekt het de script al, en dat is echt frustrerend.
Maar goed, dit is mijn ervaring en mening

[thePiett]

Dat ben ik zeker met je eens. Ik heb nooit kunnen wennen aan de syntax van Python; just omdat ik punt-komma's en braces mis. Het is minimalistischer dus ik kan me voorstellen dat iemand dat prettiger vindt, maar geef mij maar de "classic" C / Java / PHP / Go achtige syntax.

[hooibergje]

Nice! Goede notification.
Meteen nieuwe Python op ons cluster geinstalleerd.
Zijn 128 gebruikers weer bij de tijd.

[Osiummaster]

ohhh jottem we zijn er bijna https://charlesleifer.com...s-planned-for-python-4-0/

[Elfjes]

Haha, mooi!

Saillant detail hierop, de nieuwe parser die in 3.9 wordt geïntroduceerd (PEP 617), maakt het mogelijk om in python 4.0 3.10 het match-statement te implementeren (PEP622), een soort switch statement on steroids . Dus switch statements komen er toch

[BezurK]

Maar we noemen het geen switch of case, dus dat is het niet. Het is match!

[doc]

Python 4 FAQ.
1. The version after 3.9 is 3.10; in fact it already exists (in github master).
2. If there ever is a version 4, the transition from 3 to 4 will be more like that from 1 to 2 rather than 2 to 3.

[maarten_db]

De volgende wordt gewoon 3.10.
Zie https://twitter.com/gvanrossum/status/1306082472443084801
Een volledig pijnloze transitie bestaat niet, maar ik denk dat ze bij de 2 naar 3 wel hun lesje geleerd hebben.

[MaestroMaus]

Er zijn een aantal mensen hier die nog maar eens het woord satire op moeten zoeken in hun woordenboek. Oef...

[Osiummaster]

>You can now use the async keyword before every single other keyword in the Python language, and we encourage you to async do so. There's nothing wrong with cargo-culting some magic keywords all over the place -- you want to go fast, don't you?

[Flghter1982]

nondeju. ik ben net begonnen met pyton 3.8 leren

hoop dat het niet teveel veranderingen met zich meebrengt.

[84hannes]

hoop dat het niet teveel veranderingen met zich meebrengt.

Dat komt wel goed.

Er was een tijd dat een nieuwe Linux-kernel een wereld van verschil maakte. Ik kan me de update van 2.2 naar 2.4 nog herinneren opeens kon je USB gebruiken. De laatste grote verandering was 2.6.0, dat was bijna 17 jaar geleden.
Er was een tijd dat iedere Windows-versie een revolutie was, zoals van Windows 3.1 naar 95, met het startmenu in plaats van de programmabeheerder. Windows 10 was de laatste grote verandering, dat was ruim 5 jaar geleden.
Er was een tijd dat elke C++-versie een nieuwe manier van programmeren was, zoals toen C++11 werd geïntroduceerd en we het era van "modern C++" betraden (waarin bijvoorbeeld ruwe pointers niet meer nodig zijn). Dat was 9 jaar geleden.
Er was een tijd dat Python een grote verandering in één keer doorvoerde, van 2.7 naar 3.0. Opeens werkten alle packages voor 2.7 niet meer op de nieuwste versie en menigeen is jarenlang op 2.7.x blijven hangen. Dat was12 jaar geleden.

De tijden van grote updates lijken voorbij. Er komen van alle bovenstaande projecten veel vaker updates dan vroeger, maar de updates zijn ook veel incrementeler. Windows, C++, Linux en ook Python zijn inmiddels volwassen: er zijn weinig schokkende vernieuwingen meer nodig, maar elke nieuwe versie brengt een paar dingen die het leven beter maken; en twee keer zoveel dingen waarvan je je afvraagt waarom je dat ooit zou willen. Maar daar heeft iemand anders waarschijnlijk iets aan.

[Reactie gewijzigd door 84hannes op 24 juli 2024 05:22]