 Au début de Python 3, il y avait un projet qui s'appelait Python 3000. C'était en 2006. Il a commencé avec un PEP, le PEP 3000, qui s'appelle Python 3000. Et l'idée était de focusser sur ce qui s'appelle Python Warts. Parce que Python 2 a beaucoup plus d'utilisateurs, et souvent, les gens ont commencé à compléter des issues de design. Et ce sont des issues de design qui ont commencé à être collectés à la liste, et ils étaient appelés les Python Warts. Par exemple, dans Python 2, vous avez deux types différents pour les intégres. Vous avez le long intégre et le petit intégre. Et selon la valeur du nombre, selon l'opération, vous pouvez avoir un petit ou un grand intégre. Et dans ce cas, si vous avez des types différents, vous avez à tester pour les deux types en même temps. Et cela peut être surprise pour les newcomers. Ils ne peuvent pas comprendre pourquoi nous avons deux types différents pour les mêmes valeurs et le nombre. Il y a aussi quelque chose qui s'appelle la nouvelle classe. C'est une nouvelle édition durant le développement de Python 2. La nouvelle classe doit être utilisée pour obtenir de nouveaux outils, comme, par exemple, les propriétés de Python. Si vous n'utilisez pas la nouvelle classe, les propriétés ne fonctionnent pas comme expected. Et encore, c'est un petit peu surprenant que vous devez évoluer explicitement d'un type objectif pour obtenir de la nouvelle classe. Et c'est surprenant pour les newcomers. Pour la division de deux intégres en Python 2, vous obtenez un intégre. C'était une décision faite depuis le début de Python. Mais quand Python devient plus et plus populaire, des gens ont été surpris qu'ils n'ont pas des outils, parce que dans d'autres langues, en utilisant un simple calculateur, vous obtenez des outils. Donc, cela a été décidé de changer cela pour toujours obtenir des outils, parce qu'il y a déjà un opérateur en Python 2. Mais si vous n'utilisez pas la nouvelle classe, vous obtenez toujours un intégre. Pour l'unicode, je voudrais dire que si vous n'utilisez pas les outils, vous êtes bien. Si tous vos outils, toutes vos outils, toutes les données dans votre application n'ont pas d'outils. Il n'y a pas d'issue. Mais si vous utilisez l'unicode en input, d'outils, l'unicode tout dans votre application, vous êtes aussi bien. Mais si vous commencez à obtenir des outils, quand vous avez des outils et d'unicode dans votre application, spécialement, vous n'aurez pas d'outils tout le temps, mais seulement si un seul caractère a un accent. Donc, c'est un peu difficile de débarguer l'issue 3. Cela peut arriver en production. Et plus et plus de gens sont anglais contre le design. Pour comparaison, Python 2, de nouveau, a créé une option de l'initialité, c'est que vous êtes toujours capable de comparer les deux variables dans Python 2. Cela signifie que si un objectif n'a pas de sens pour comparaison, Python prend le nom du type et comparer le nom. Par exemple, si vous comparer le nom Hello et le nom Free, vous avez le nom S tier pour le type Spring, et vous avez le nom Int pour le nom Free, et vous comparer les deux variables pour décider comment to order values. Et ce comportement peut être surprenant, et peut-être pas le genre que vous pouvez imaginer. Donc, nous avons aussi décidé de changer ça, et de ne pas essayer de l'imaginer, mais de créer un type Power dans Python 3. Cela signifie que dans Python 3, vous devez le faire très explicitement. Et enfin, pour les imports, une autre option pour les newcomers, c'est que si vous avez un module qui a le même nom que le module de l'étudiant standard, comme le Sys module, vous avez un conflit entre le module de l'étudiant standard et votre projet. Parce que Python a décidé de utiliser quelque chose de relatif pour les imports, ce qui signifie que vous pouvez importer un module dans la même direction sans avoir à spécifier le path pour le module. Donc, encore une fois, nous voulions changer ça pour toujours utiliser des imports absoluts, ce qui signifie que vous devez toujours utiliser le path pour le module pour éviter un conflit de nom. Donc, pour faire sure que Python 3 n'est pas un grand erreur depuis le début du projet, nous avons essayé d'avoir quelque chose qui s'appelle le risque management, pour ne pas briser tout. Et la idée c'est de seulement changer l'accompagnement des wards, donc seulement la très petite liste des issues de design. Et nous avons également décidé d'avoir un processus de communité pour décider ce qui devrait être changé et le processus, où le PEP, avec un nombre qui a commencé avec 3000, et nous avons également décidé de ne pas réimplier Python de scratch, le C Python, l'implementation de la langue, ce n'est pas fait de scratch, mais c'est juste un fork de Python 2. Encore, c'est de limiter les changements subtels que vous pouvez obtenir si vous le faites de scratch. Et de la même manière, depuis le début, nous avons décidé de mettre en ligne un deadline pour Python 2. Au début, c'était 2015, je pense, pour dire que aujourd'hui, vous êtes bien avec Python 2, mais prenez soin d'être préparé à ce moment-là. Et en 2008, c'est la première édition de Python 2. C'est la première édition. C'est la première édition. Et c'était 10 ans auparavant. Et la première édition du plan était très simple. Vous prenez votre application, toutes les dépendances, tout. Vous prenez une application de 2 à 3, pour convertir vos codes Python 2 à Python 3, et c'est fait. Ok. Peut-être que ce n'était pas assez facile en pratique. Peut-être qu'il y a des issues pratiques. Parce que la chose est que quand vous avez une troisième partie de la dépendance, le moteur de la module peut-être ne veut peut-être pas couper les codes Python 2, parce que quand vous roulez à 2 à 3, vous vous perdez Python 2 support. Et quand Python 3 a été élevé, Python 3 était une nouvelle chose. Ce n'était pas supporté par la distribution Linux, pour exemple. Ce n'était pas installé par la plupart des utilisateurs. Ce n'était vraiment quelque chose de très nouveau. Donc beaucoup de utilisateurs ne voulaient pas entendre quelque chose de Python 3. Et un autre issue pratique c'est que même si vous succez de porter une dépendance à Python 3, ce n'est pas assez. Vous devez vraiment porter une dépendance de la dépendance 0. Et donc vous ne pouvez pas commencer à porter votre application avant que vous portez les dépendances. Donc ça prend beaucoup de temps juste pour commencer sur votre propre code. Et un autre bad ou bien surprise c'est que nous n'avons pas que Python 2 était tellement populaire et que c'était très utilisé en production. C'est un problème de technique imaginez que vous parlez avec votre manager et que votre manager vous demande pourquoi je dois vous faire du travail sur Python 3 et le développeur dit que pour tous ces nouveaux features de Python 3 et le manager ok, mais peut-être que je peux utiliser ces features ? Nous devons toujours supporter Python 2 non parce que Python 2 et Python 3 dans la même base de code techniquement, vous ne pouvez pas utiliser Python 3 parce que vous devez supporter Python 2 donc vous pouvez prendre beaucoup de temps pour porter tout, mais au final vous n'aurez pas de directs bénéfices de les portes. Donc vous devez prendre beaucoup de temps pour ne pas encore, c'est difficile de justifier si vous êtes un manager de vous. Si vous voulez porter une application de Python 3 vous avez différentes options pour la base de code par exemple vous pouvez décider d'avoir deux branches différentes dans Geats et un exemple est que le projet DNS Python a été forked il y avait deux projets différents DNS Python pour Python 2 et DNS Python 3 pour Python 3 parfois le maintainer de ce projet ne cares pas Python 3 parce que c'est l'appel du manager Harry et la communauté a décidé de forker les projets par exemple, le module PIL a été forké comme pilau c'est un module pour manipuler des photos pour resserrer et faire des photos et pas seulement j'ai ajouté Python 3 support mais j'ai aussi ajouté de nouveaux features ce qui est vraiment cool et dans le meilleur cas vous êtes stocké par une dépendance comme MySQL Python et tout le module PIL mais le maintainer a décidé de ne pas reposer à d'autres reportages il n'a pas reposé à un pull request donc nous étions stockés et nous ne savions pas ce qu'il faut faire donc quelqu'un a décidé de forker le projet et lui mettre le nom et puis vous avez un nouveau problème pour les vendeurs Linux comme Red Hat il faut que vous reliez à la nouvelle version ou la nouvelle version parce que nous ne savons pas si la nouvelle version va mourir ou si elle va être maintenue pour le maintainer pour vous donner une idée de ce que c'était Python 2 à cette époque, vous devez savoir que quand Python 3 a été créé la version stable de Python 2 a été 2.6 et le problème avec Python 2.6 c'est que vous devez faire beaucoup de changements pour que votre code soit compatible avec Python 3 pour l'exemple, pour tout le code d'un code d'un code nous avons un prefix U pour annoter un code d'un code mais si vous faites ça vous avez un syntaxe Error dans Python 3 pour avoir un code single pour un code d'un code donc vous devez écrire 6.U parantéz votre code c'était un petit peu anonyme pour faire ça sur tout votre code parce que c'est un projet qui a décidé de ne pas faire quelque chose pour Python 3 un autre problème c'est que si vous voulez utiliser de nouvelles features Python 3 comme la nouvelle méthode de l'unit test vous pouvez utiliser quelque chose qui remonte de nouvelles features de Python 3 mais c'est peut-être un problème d'avoir une dépendance parce que 10 ans auparavant c'était un petit peu difficile d'installer toute la dépendance et de prendre soin c'était plus difficile d'installer ça donc nous devons attendre à Python 3.2 vous avez un issue U merci pour ça donc après Outon vient le temps de winter et nous allons commencer avec un web site appelé Python 3 Wall of Shame donc en 2011 quelqu'un a décidé de créer un web site appelé Python 3 Wall of Shame mais l'idée n'était pas de blâmer l'autor des modules l'intent était de motiver pour le code Python 3 mais quand le web site a été créé seulement 9% de les top 200 modules étaient compatibles avec Python 3 et pour rappeler ce que l'a été Python 10 ans auparavant nous avons eu 3 grands joueurs dans la communauté Python il y a un tristis qui est une solution très bonne pour clients sur le service pour faire un programme asynchronous qui est un moyen très efficace pour faire networking dans Python il y a un mercuriel qui est similaire pour GIT et les résultats sont aussi Django, un framework très fameux pour faire web sites et il y a 3 projets qui ont différents sujets avec Python 3 Tristis et mercuriel sont très proches pour le hardware, pour le level laud par exemple Tristid et sur le level socket le level network il n'y a rien de code unicode il n'y a qu'une byte tout le projet est créé pour utiliser bytes et en Python 3 n'est pas le premier type class de citizen nous préférons utiliser unicode au début c'était un peu difficile pour Tristid pour pour le code base pour Python 3 c'est la même issue pour mercuriel parce qu'ils utilisent bytes pour le code fin pour une très bonne raison mais aussi pour le contenu de file pour les deux résultats c'était aussi difficile et c'est toujours difficile pour mercuriel pour Python 3 et pour Django quand Python 3 a été créé le support d'unicode était seulement au début parce que c'était très difficile pour le code port parce que personne ne veut être le premier qui est Python Troll et Python Troll considère que Python 3 ne tient rien parce que comme j'ai expliqué avec le manager, quand tu portes le code Python 3 tu n'as toujours les mêmes features tu n'aimes rien et quand tu parles de Python 3 tu es obligé d'utiliser unicode et personne ne veut faire ça parce que c'est très difficile pour une bonne raison et c'est beaucoup plus simple d'utiliser Python 2 avec Python parce que tu n'as pas de risques d'unicode personne en parlant des langues différentes juste passe le texte et ça marche Python 2 Python 2 est un fail donc peut-être que ce que nous pouvons faire c'est juste continuer le développement de Python 2.7 donc il y a une idée de Python Troll c'est que peut-être que nous pouvons juste continuer d'utiliser une nouvelle version de Python 2.8 pour ajouter de nouvelles features de Python 3 mais ne détectez pas la compatibilité de base et il y a 4 ans il y a encore un article qui dit qu'on était toujours débattant de la transition Python 2.8 et ils étaient concernés que Python 3 ne tiendra pas et aussi que Python 3 ne représente que 2% pour faire des choses plus explicites on a écrit un PEP appelé PEP Not Found c'est le 404 c'est Python 2.8 Un release schedule donc c'est un document très explicite pour dire qu'on sait qu'on se débrouille la compatibilité de base mais on ne va pas prendre plus de temps sur Python 2 parce qu'on est un petit équipe et on n'a pas assez de temps pour maintenir deux versions et si vous utilisez les numéros différemment en 2013 quelqu'un d'autre compte c'est 80% du top 50 projects qui étaient compatibles avec Python 3 donc ce n'était pas si mal et Python 2.7 c'est l'end of life extended à Python 2014 et pour moi, c'est l'un des meilleurs que nous avons fait pour Python 3 c'est qu'on a dit ok, on sait que c'est difficile pour le code portugais vous avez une bonne raison pour pas pour le code portugais aujourd'hui parce que pas toutes les dépendances sont compatibles parce que ça coûte beaucoup de money et on n'a pas envie de forcer les gens de bouger pour Python 3 on n'a pas envie de forcer les gens pour faire quelque chose 5 plus ans pour faire votre travail et on a étendu l'end of life to 2020 donc après le winter il y a l'air fresh les flowers c'est un nouveau début et le premier grand mouvement pour Python c'est que notre premier problème a été réservé donc ce qui est notre premier problème c'est que quand on veut, on installe la dépendance c'est une question très commune parce que l'utilisation de la dépendance c'est une bonne pratique la question c'est comment je peux installer la dépendance et la réponse c'est oh, vous devez installer les secteurs ok, mais comment je peux installer les secteurs et c'était un peu difficile parce que vous devez trouver un script sur internet pour downloader le script vous avez besoin d'un administrateur d'être capable d'installer le script il installe quelque chose sur votre système ce n'est pas du système c'est de l'internet donc vous devez l'assurer ce n'était pas la meilleure solution mais en 2011 PIP 1.0 a été élevé et en 2014 nous avons décidé d'incluer pas PIP mais NSurePIP qui est un nouveau module pour installer PIP directement à Python donc à Python 2.7.9 et à Python 3.4 il n'y a pas d'intro PIP pour être installé très facilement en pratique même si vous n'avez pas de connexion sur internet vous devez encore pouvoir installer PIP en utilisant ça et grâce à ce changement lentement PIP devient un défacteur installeur et vous n'avez pas besoin de comment installer la dépendance PIP est la manière correcte de faire ça et on voit aussi l'installation linux pour inclure PIP directement dans le système donc aujourd'hui c'est très facile d'avoir des dépendances pour apporter une application pour Python 3 nous avons vu que 2.2.3 n'était pas la meilleure approach donc ce que nous avons vu c'est que peut-être nous ne devons pas retirer Python 2 support mais dire différemment Python 3 support et c'est un grand changement parce que vous n'en perdez pas vos utilisateurs vous n'avez pas besoin d'apporter Python 3 step by step et vous n'avez pas besoin de poursuivre toute votre dépendance de votre codebase tout à l'heure vous pouvez commencer avec un changement simple ou un single file et faire ça incrementale et nous avons commencé à voir des nouveaux outils comme Modernize et Python 2 support et nous allons utiliser la histoire de Sixer, qui est mon seul outil donc je travaille sur OpenStack et en OpenStack si vous sendez un pull request generated par Modernize vous avez un grand pull request et vous êtes sûr que dans quelques heures vous allez avoir un conflit parce que OpenStack va très rapidement et tous les files sont modifiés donc c'est très difficile d'avoir un pull request avec aucun conflit pour plus d'un jour spécialement un grand pull request donc ce que j'ai fait c'est d'écrire un nouveau outil qui n'applique qu'une sélection d'opération comme par exemple juste ajouter parmentés pour le print statement et en faisant ça vous pouvez générer un plus petit pull request et vous avez plus de conflits et c'est beaucoup plus facile de review pour le maintainer parce que vous voyez que le changement n'a pas de parmentés donc c'est une simple changement et c'est facile à approcher et grâce à cet outil j'ai pu poursuivre tous les tests d'OpenStack pour Python 3 et un autre bon avantage de cette méthode c'est que si vous avez un CI pour valider tout votre travail vous pouvez faire sure que chaque changement n'a pas la compétibilité de backyard il n'a pas introduit la régression donc vous pouvez appliquer un par un et faire sure que tout est bien si vous avez un gros codebase peut-être que vous avez besoin de faire ça différemment parce que certaines compagnies ont un très très grand codebase comme par exemple Instagram ou grabbox ont à moins de 2 millions de codes donc ce qu'ils ont besoin de faire c'est que quand vous avez un très très grand codebase ce que vous pouvez faire c'est d'abord pour ajouter un nouveau test parce que parfois dans une grande compagnie les gens préfèrent ajouter un nouveau codebase mais ils n'oublient pas pour ajouter un nouveau test donc ajouter un nouveau test c'est une bonne pratique pour votre codebase existant mais ça aussi aide à faire sure que la migration n'a pas de problème et grabbox est aussi essayant d'une certaine approche j'ai décidé de travailler sur la type annotation et de noter les arguments de votre fonction mais aussi le type de retour de votre fonction et en faisant ça ils pensent que c'est beaucoup plus facile pour poursuivre l'application pour Python 3 parce que si vous avez un type annotation, vous savez quel type vous avez attendu et c'est beaucoup plus facile d'assurer que vous validatez tout pour faire la migration simple nous avons fait différents changements en Python mais aussi en tournant en Python et le premier grand changement c'est que en 2012 nous avons décidé de réintroduire le Uprefix même si ça n'a pas de sens si vous regardez seulement le Python 3 pour avoir des Uprefix parce que tous les strings sont unicodes par défaut ajouter le Uprefix était très utile d'aider un codebase single donc c'est fixé beaucoup d'issues pour aider les gens à poursuivre le code en 2015 Python 3.7 a été créé avec un nouveau opérateur pour bytes c'est un moyen de formuler un byte string c'est très utile pour un projet comme Twisted ou Mercure qui manipule beaucoup de bytes et nous avons aussi ajouté Python 3000 warnings Python 3000 warnings nous avons ajouté ces warnings en Python 2 c'est l'idée que même si vous n'en portez rien n'évoquez pas le warning et vous verrez quel code peut avoir des problèmes sur Python 3 et vous devez avant de commencer le plan de migration pour pouvoir utiliser Python 3 features nous avons vu plus et plus de backports de Python 3 features Python 2 par exemple unit test 2, enume 3 4 qui est un nouveau module enume et grâce à tous ces backports de bouger à Python 3 il y a beaucoup de choses et après le spring c'est le temps pour revenir sur le site The Wall of Shame le site a décidé de changer le titre de Wall of Shame pour Wall of Super Power et aujourd'hui nous avons presque 100% de modules compatibles avec Python 3 en pratique c'est un peu moins c'est seulement 90% parce que dans cette longue liste vous avez des modules qui ont été répliqués par des nouveaux modules parce que tout le module n'a pas de sens sur Python 3 ou le maintainer a décidé de restarter de scratch donc dans cette liste vous avez des modules qui vous pouvez juste ignorer et vous pouvez considérer que c'est les top 200 modules sur API qui sont compatibles avec Python 3 et une autre bonne news pour Python 3 c'est que après un long process de développement nous avons eu assez de temps pour optimiser Python 3 et Python 3 est plus rapide que Python 2 sur cette graphique vous pouvez voir les résultats de quelques benchmarks et la ligne orange est le résultat normal de Python 2 donc c'est toujours 1 c'est à dire que Python 3 est plus rapide et vous pouvez voir que selon les benchmarks c'est plus ou moins rapide et en quelques cas c'est plus rapide pour vous donner ces numéros différemment, il y a une compagnie Instagram qui a 700 millions de utilisateurs donc c'est une grande application de Django qui se tourne tous les jours sur la plateforme mobile c'est un gros produit c'est fully written in Python et ils ont switché à Python 2 Python 3 et grâce à ce mouvement ils ont sauvé 12% de CPU juste par le changement et ils ont aussi sauvé 30% de la mémoire ce qui est très important pour eux parce que quand vous avez beaucoup d'utilisateurs vous avez besoin de beaucoup de services et à la scale de la performance c'est vraiment utile d'avoir beaucoup de hardware et si vous ne l'avez pas remarqué Python 2 est un peu un peu trop old aujourd'hui et même si nous faisons notre mieux pour fixer tous les bugs parfois nous ne pouvons pas fixer des issues parce que la chose avec Python 2 c'est qu'il est super stable parce que nous avons beaucoup de gens qui relient à Python 2 ça veut dire que si vous faites un changement dans Python 2, même pour fixer un bug il y a un risque que quelqu'un relient sur Python 2 et que toute l'application relient à Python 2 et donc nous pensons que nous devons fixer à Python 2 et parfois c'est un issue de design pour qu'on ait un grand changement dans la langue par exemple, le premier bullet est un code unicode même si techniquement nous pouvons essayer différentes options dans Python 2 pour avoir de nouvelles warnings nous avons décidé de ne toucher la implementation du code unicode parce que, comme j'ai dit, beaucoup de gens relient à ça et nous ne pouvons pas changer le code unicode dans le monde un autre exemple c'est que pour la raison de la sécurité nous avons décidé de régler l'ordre d'items dans un dictionary et de mettre un objectif dans Python 3 parce que si vous injectez des clés spécifiques dans un dictionary vous pouvez avoir la meilleure complexité d'un type de dictionary vous pouvez cacher le serveur juste par envoyer un peu de bytes pour un service HTTP donc ce que nous avons fait c'est de régler l'ordre mais nous ne pouvons pas faire ça dans Python 2 parce que si vous changez l'ordre de la dictionary la représentation de la dictionary change et il peut briser beaucoup de tests donc pour votre information vous pouvez utiliser l'application d'application d'envoyer le workaround pour la question de la sécurité un autre issue de Python 2 c'est que le module sub-procès n'est pas safe donc peut-être que vous n'aurez pas l'air parce que vous n'aurez pas l'air ou peut-être que vous n'aurez pas l'air parce que vous n'avez pas l'air mais l'idée de pas être safe tout est bon tout est bon tout est bon jusqu'à un jour en production vous avez un crash et personne ne peut reproduire parce que il dépend vraiment de le workload il dépend vraiment de l'ordre de l'opération sur votre développeur laptop vous avez différentes timings donc c'est très common que la condition de l'aise s'occupe en production donc personne ne veut faire quelque chose qui n'est pas safe so be careful with the sub-procès and for new information there is a back port called sub-procès 2-3-2 which back-ports the safe implementation another example is the recursive lock which again is not as a race condition race conditions are not threads but signals it means that if you use recursive lock and you get a signal signal is for example that you spawn a process and when the child process completes you get a notifications to say that hey your child completed it's time to read the status the exit status of the process so when you get the signal you may get a race condition and your lock may become inconsistent so you may get a dead lock just because of a signal and this is really annoying because signal can come anytime it really depends on the timing of the child process and you don't control the timing of the child process so it's really dangerous to use a recursive lock on python 2 another example is that clocks in python 2 use a system time so during winter time or summer time when you use a change of clock for DST your application may crash just because of that or for example if the system administrator decided to change the time manually again you may get a crash and the solution for that is to use something called monotonic lock monotonic lock only increase there is no jump in the future or in the past so the good news is that you just have to switch to python 3 c'est fine so for example for the time in python 3.3 I added the time.monotonic function and slowly we modified python to use monotonic clock inside python and to explain you something else about python 3 as I said python 2 is super stable we cannot touch anything and the good thing with python 3 is that it's still kind of not as popular than python 2 so we can afford to make more backward uncomfortable changes for example I change how file descriptor are inherited by child process and since python 3.3.4 when you spawn a child process you don't inherit the file descriptor it means that you don't inherit open socket you don't inherit c'est fine which contain password but this was our backward compatible changes and we cannot do such change in python 2 and another example is that in python 3.5 I made another change which is to when you get a signal the c'est call is interrupted you get an error and the behavior in python 2 is that you get an exception and you do something and in python 3.5 is that if the signal handler doesn't raise an exception python will just retry the blocking c'est call for you and you don't notice anything you're just fine and we'll have an resume when he approved my change for the file descriptor he wrote that we are aware that the code breakage and doing it anyway for the good of mankind and again python 3 is much much better because you have a lot of new modules in the standard library I counted 21 modules for 3.7 just to give you some examples there is asyncio for asynchronous programming there is enium for enium which is very useful there is passlib which is very popular to manipulate pass there is unitest.mock which is a very very nice way to reduce the dependency of a unitest and really test something very specific so to mock another function and not only we fixed bugs and we added new features we also made changes in the language and for example in python 3.6 we added something called the fstring it's a new way to format string and in my opinion it's just the best way to format string because it's very short it's very obvious when you read the string and yeah it's just the best because not only you can format a variable but you can even call a method you can in practice you can add any python expression it just works it's amazing and for asynchronous programming we made different changes first we added a yield from after that we added async on our weight keywords and we also added support for asynchronous generators so yield inside an asynchronous method there are asynchronous list comprehension but you have also more changes like for example we have the keywords only arguments it's very useful to write a better API the prints is no longer a statement but it's a function and I really prefer to have this function you can use the star to unpack but also to inside a list now you can use the star this is a new feature it's a new way to build a list and in my opinion it's straight forward and very useful you can use underscore inside numbers to make numbers easier to read you can annotate the type of variable for the context manager with statements you can add multiple expressions there is again the bytes formatting and there is something very useful for non-py users there is a new operator for matrix which is at it avoids this is an infix way for matrix operation because previously you had to call a function and it was harder to read so I spend a lot of time to explain that Python 3 is way better and we are reaching slowly the deadline which is 2020 deadline of Python 3 Python 2 so the question is now is it time to maybe bury Python 2 so the good news is that in Fedora we already started to do that 3 years ago in Fedora 2023 there is no Python 2 by default there is only Python 3 by default and in the release of human 2 last year there is no Python 2 by default only Python 3 and there is a Python 3 statement which is a common timeline for all applications for the end of support for Python 2 in their application and there are big projects like iPython 6 and Django 2 which dropped Python 2 and I'm working for Red Hat so for your information in the latest release of Red Hat 7.5 we announced that Python 2 is deprecated so if your manager still have concern about Python 2 you can say that even Red Hat which has a very very long support we are aware that something is wrong with Python 2 and we are working on that and for your information the next release of Red Hat Enterprise Linux will be Python 3 only and this is thanks to my very cool colleagues that we are working on that for 2 years and if you use Red Hat Enterprise Linux or CentOS there is also something called software collections which is a way to install the latest version of Python on your old system so technically it's already possible to use Python 3 on Red Hat and one open question for me is that we saw that changing the syntax and changing Python was really difficult so maybe we can try to under this issue differently and maybe try the JavaScript issue solution which is to use transpiling using Babel and Polyfill and by doing that you are able to use the latest language on your old browser and thanks to that they are able to move way faster because you are no longer stuck by the version of JavaScript on your browser you can use new features ok ? Question ? Thank you so much Thank you we have time for a few questions maybe if there's I've seen one over there Just to come back to the latest slide to be honest Python 2, that's Python 3 was a huge pain for everybody and if we do that one more time we will not afford to break everything and my expectation is that Python 4 will just be the release after the previous Python 3 release and we will follow the same deprecation process to have a slow process to give at least two release to remove something so we are not going to break Python one more time Ah, that's good to hear I just was wondering whether the chart about performance was like generic case because it puzzles me a bit and the point is that from what I saw around the internet usually Python 2.7 performed faster on the general computing but is there like a usage of a sync or something like that which drastically changes the chart or it's like the general case I spent a lot of time to work on benchmark because I wanted to optimize Python so this chart comes from a project called performance it's a sweet benchmark suite so I'm not sure that they are real representative of real applications but we are trying to be to use more complex benchmark to have a better idea of what is a Python performance on what I just can say that on this benchmark suite Python 3 is always faster there is only one case where Python 3 is slower but we are working on that and it's getting better so I'm sure that in some specific cases Python 2 is still slower but the good news is that this chart is for Python 2.6 it's an old chart but Python 3.7 is even faster so maybe we should try the latest version of Python because we optimized the method call and many other small changes one last question is there any so knowing how the transition went what would you do differently if you could do Python 3 again I tried to explain that ten years ago the choice that we made was a good way to do that because we didn't have enough information that we didn't know that we had so much users we are not aware of the big dependency chain so yes if I do that again what I would do is just to have a very smooth transition to make sure that even if we break something we have a lot of time to port the code and not to push all backward incompatible changes at once but do them one by one and make sure that we have the right tooling to do the conversion right tooling to detect issues in your code because one of the very difficult issue of Python 3 is that when you divide two integers you get a float and this specific issue is really difficult to catch in your code because just by reading the code you don't know the type so we need more tooling to detect that and to help users ok, thank you so much