Łukasz Langa vient d’annoncer au nom de la PSF la disponibilité de CPython 3.8, l’implémentation de référence. Cette version est particulière puisqu’elle introduit une syntaxe controversée : l’assignation avec l’opérateur :=
qui permet d’assigner dans une expression et plus seulement dans un statement.
Le nombre de changements est assez impressionnant. Malgré la maturité de Python et sa popularité, il y a encore à faire !
Pour les systèmes stables, la version de référence reste la 3.6. Pour les autres, profitez de pyenv ou Docker pour utiliser les nouveautés de ce bon cru ! Découvrez‐les dans la suite de cette dépêche.
Sommaire
Opérateur d’assignation
Jusqu’à présent, Python refusait tout simplement d’assigner une variable dans un if
ou équivalent. Concrètement, if var = True:
lève une erreur de syntaxe. Cela évite l’erreur classique d’assigner une valeur en oubliant le deuxième égal de l’opérateur de comparaison ==
. Dans les langages autorisant l’assignation dans les expressions, l’utilisation de condition Yoda aidait à se défendre d’une erreur humaine. Dans Python, c’est, de toute façon, impossible.
Mais voilà, il y a certains cas où l’assignation et le test sont très liés. Et l’opérateur d’assignation est très pratique. Le cas le plus courant est l’exécution d’expression rationnelle :
m = re.match('motif', 'valeur')
if m is not None:
...
À partir de Python 3.8, un opérateur particulier permet d’assigner et de vérifier la valeur : l’opérateur :=
. Les Anglo‑Saxons l’appellent walrus, c’est‐à‐dire morse (comme l’animal), car il ressemble à un smiley représentant les yeux et les défenses du morse. Désormais, on peut écrire le code précédant comme suit :
if (m := re.match('motif', 'valeur')) is not None:
...
La concision de cet opérateur est appréciable. Et il est difficile de le confondre avec l’opérateur de comparaison.
Le grand débat
Cet opérateur a été l’occasion d’un débat passionné. Est‐ce que cet opérateur est une variation de ==
ou bien faut‐il réutiliser le mot‑clef as
comme dans except Exception as e
?
Guido van Rossum, créateur du langage, a utilisé son super‐pouvoir pour imposer le petit morse. Mais cela lui a coûté et il a démissionné de son poste de BDFL.
Arguments exclusivement positionnels
Python permet déjà de déclarer des arguments de fonction exclusivement nommés. Python 3.8 ajoute la possibilité de déclarer des arguments exclusivement positionnels. Voici un exemple :
def f(a, /, b):
print(a, b)
f(0, 1) # valide
f(a=0, b=1) # invalide car a est nommé
f(0, b=1) # valide
Certaines API en tireront parti pour simplifier la validation des arguments. À noter, le nom d’un argument positionnel peut être réutilisé en argument nommé. Par exemple :
def f(a, /, **kw):
print(a, kw)
f(0, a=1) # valide ! Affiche: '0 {"a": 1}'
Interpréteur async
Cette nouveauté n’est pas mise en avant, pourtant elle est bien pratique. En exécutant le module asyncio
, CPython propose désormais un interpréteur Python acceptant le mot clef await
pour exécuter une co‑routine :
Avant :
$ python3
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> await asyncio.sleep(1)
File "<stdin>", line 1
SyntaxError: 'await' outside function
>>>
Désormais :
$ python -m asyncio
asyncio REPL 3.8.0
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> await asyncio.sleep(1, result='hello')
hello
On pouvait avoir à peu près lʼéquivalent en lançant une boucle par co‑routine :
$ python3
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> asyncio.run(asyncio.sleep(1, result='hello'))
'hello'
>>>
À suivre !
Pickle v5
Pickle est un protocole de transmission de données dans un format interne à Python. Le Français Antoine Pitrou a proposé une version 5 du protocole permettant de référencer des données transmises hors bande. Cela permet d’utiliser un canal de communication plus performant pour les gros volumes de données qu’on veut transmettre à Python.
Petit rappel, Pickle n’est pas un format pour communication publique. Il est très facile d’injecter du code dans votre programme via ce protocole. Utilisez‐le uniquement pour les communications internes à vos projets.
Et plus
Le mini‐langage de formatage de chaîne accepte un nouveau spécificateur f-string : {var=}
qui affiche le nom de la variable et sa valeur. Cela économise une duplication lorsqu’on écrit des messages de débogage.
CPython peut maintenant stocker les fichiers bytecode dans un dossier de cache spécifique, ailleurs que dans des dossiers __pycache__
un peu partout. Il faut pour cela définir le paramètre PYTHONPYCACHEPREFIX
via différentes méthodes. Cela permet, par exemple, de livrer du code source en lecture seule, sans précompiler, tout en laissant la possibilité d’avoir un cache de bytecode parallèle.
Le travail du Français Victor Stinner sur l’optimisation de l’appel de fonction a été amélioré avec un nouveau protocole d’exécution nommé vectorcall
. Pour le moment, c’est de la cuisine interne. Python 3.9 devrait exposer davantage d’optimisation possible dans le code Python.
On peut désormais spécifier un caractère Unicode par son nom dans les expressions rationnelles avec \N{NOM UNICODE}
plutôt que par son code ou son encodage UTF-8. Ainsi, r'\N{EM DASH}'
équivaut à '—'
ou '\u2014'
. La notation \N
permet d’utiliser le mode brut r''
incompatible avec \uXXXX
.
python -m json.tool
accepte désormais un objet JSON par ligne avec l’option --json-line
. Ce cas est courant avec les journaux au format JSON.
Il reste moult nouveautés et changements à découvrir. N’hésitez pas à consulter la longue page des nouveautés de cette version 3.8, notamment la section sur les API obsolètes retirées et les conseils de migration. Bonne découverte !
Aller plus loin
- Détails des changements de Python 3.8 (213 clics)
- Guido van Rossum se retire de la direction de Python (215 clics)
# Merci
Posté par Alex G. . Évalué à 10.
J'ai trouvé le résumé vraiment bien fait avec un bon équilibre ni trop synthétique ni trop bavard.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Version de référence
Posté par med . Évalué à 2.
Pourquoi pas 3.7 ? Python ne fait pas de différence entre les versions paires et impaires.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Version de référence
Posté par Alex G. . Évalué à 5.
Pour donner un cas concret, Django 3 aura le support des version supérieur à 3.6.
[^] # Re: Version de référence
Posté par dam1605 . Évalué à -1. Dernière modification le 17 octobre 2019 à 17:36.
Je ne sais pas s'il a compris, mais moi non.
edit: finalement je crois qu'en fait si.
# Coquille
Posté par lerat91 . Évalué à 0. Dernière modification le 16 octobre 2019 à 07:59.
Le est devrait être et.
Très bonne dépêche sinon, merci !
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
[^] # Re: Coquille
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Il y a une petite coquille dans le code aussi, le
/
manque dans le deuxième exemple de « Arguments exclusivement positionnels »:Merci pour la dépêche en tout cas, elle résume bien sans aller dans tous les détails comme l'annonce officielle.
[^] # Re: Coquille
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
Corrigé merci.
Oui c'est une dépêche agréable à lire (et à modérer).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Coquille
Posté par Storm . Évalué à 1.
Autre petite coquille dans la section "Et plus" :
Cela permet, par exemple.
[^] # Re: Coquille
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1.
Corrigé merci.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Yoda ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Qu'est-ce que c'est que cette condition Yoda ? Je comprends la référence, ça doit évoquer une expression formée de termes qui dans un ordre inhabituel sont, mais concrètement, ce que ça signifie je ne comprends pas. Un exemple ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Yoda ?
Posté par Clément V . Évalué à 8.
J'avais bien compris ça, mais c'est étrange comme nom quand on y pense. Yoda dirait plutôt
"valeur" mavar ==
("À valeur ma variable est égale"), non ?[^] # Re: Yoda ?
Posté par jihele . Évalué à 10.
C'est une erreur de script de Star Wars. C'est compliqué à corriger upstream, même dans une version majeure, tant ça aurait de conséquences question rétro-compatibilité.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Yoda ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Oui, merci.
[^] # Re: Yoda ?
Posté par barmic 🦦 . Évalué à 6.
Tu met la constante à gauche pour empêcher tout risque d'affectation. C'est le fait d'écrire :
au lieu de :
Tout ça pour éviter un malencontreux :
Qui est toujours vrai. Il y a une page wikipedia là dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Yoda ?
Posté par lym . Évalué à 2.
En même temps, c'est plus un problème sur un langage interprété.
Ça fait des lustres que les compilateurs lèvent un warning sur ce type d'erreurs sans aller vers la nécessité d'un "décodeur maître Yoda" visuel!
A ce sujet, ayant passé l'essentiel de ma vie à faire du C et ne faisant du python qu'occasionnellement (outils/test au taf ou domotique à la maison), je ne crois pas avoir vu abordé dans les dépêches les outils d'analyse syntaxiques simples et efficaces, s'il y en a, qui permettent d'éviter de ne voir les erreurs à l’exécution (et encore, si on fait en sorte de passer dans la bonne branche de code)?
Bon, ça ramènera 30 ans en arrière quand passer un coup de lint pouvait faire gagner beaucoup de temps vu les temps de compilation de l'époque… Mais si j'en avais testé quelques uns pour Python, adopté aucuns: Trop de faux positifs, configuration pénible (visant de gros projets).
[^] # Re: Yoda ?
Posté par Victor STINNER (site web personnel) . Évalué à 7.
L'équivalent en Python sont les "linters" comme pylint, pyflakes, pycodestyle, etc. Il existe aussi des analyseurs de code plus orientés sécurité comme bandit, PyT, etc.
Python se met aussi à lever des warnings à la compilation (et pas juste à l'exécution) :
[^] # Re: Yoda ?
Posté par lym . Évalué à 1. Dernière modification le 18 octobre 2019 à 14:12.
Je me rappelle en avoir essayé quelques uns (je parlais d'ailleurs d'outils lint pour le C, désormais tombés en désuétude, j'avais naturellement cherché un équivalent), mais la richesse syntaxique de Python ne me semblait pas être ici un atout: Bien trop de faux positifs à mon goût.
Pourtant, mon usage de Python étant limité, je ne crois pas faire des trucs tordus.. Peut-être pas assez "pythonic" en fait.
[^] # Re: Yoda ?
Posté par Philippe F (site web personnel) . Évalué à 2.
Peut-être que ton besoin serait plutôt autour de l'annotation de type. Jette un coup d'oeil à mypy et aux tutoriaux sur l'annotation de type (et à ma modeste conférence sur le sujet) pour voir si ça te parle plus.
[^] # Re: Yoda ?
Posté par barmic 🦦 . Évalué à 0.
J'ai pas tout compris, mais, si tu pense que le C est immunisé à ce genre de choses, il faudra en parler aux développeur du noyau linux : https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Yoda ?
Posté par lym . Évalué à 4. Dernière modification le 18 octobre 2019 à 14:00.
En même temps, depuis 2003, les chaînes de compil ont un peu évolué niveau verbosité de warning/erreur et particulièrement pour GCC, intelligibilité.
Le C laisse beaucoup de liberté et c'est très bien ainsi car là ou il est le plus utilisé c'est soit inévitable soit s'en passer a un rapport bénéfice/risque difficilement justifiable.
Alors même si tous les 5 ans on nous annonce son successeur en mieux (dont souvent des langages objet, pourtant au final toujours exclus depuis qu'ils existent car impossible d'y gérer finement l'utilisation mémoire), je pense que c'est bien le seul langage enseigné dont on peut assurer qu'il sera encore là quand ceux qui sortent d'école d'ingé actuellement prendront leur retraite!
[^] # Re: Yoda ?
Posté par liberforce (site web personnel) . Évalué à 2.
Je n'aime pas du tout cette manière d'écrire, c'est répandu, mais illisible. Tu te dis "est-ce que cette variable vaut 12", et tu dois écrire "est-ce que 12 vaut cette variable" ? On doit écrire pour la lisibilité. La manière d'éviter cela c'est d'activer les warnings du compilateur.
[^] # Re: Yoda ?
Posté par Jérôme FIX (site web personnel) . Évalué à 1.
Tourne la phrase autrement : "Est-ce que 12 est le résultat de…" :-)
[^] # Re: Yoda ?
Posté par barmic 🦦 . Évalué à 1.
Je ne comprends pas. L'égalité marche toujours dans les deux sens. En maths, tu as plus de mal avec "12 = 2*5+2" qu'avec "2*5+2 = 12" ? Quand tu apprend à résoudre des équations tu apprend à manipuler les 2 côtés de l'égalité, je vois pas comment inverser les opérandes te troubles ?
Si c'est qu'une histoire de vocalisation, tu dois bien pouvoir te trouver une phrase qui te plaira.
Dans beaucoup de cas les assertions utilisent cet ordre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Yoda ?
Posté par liberforce (site web personnel) . Évalué à 4.
Je me doute. Mais quand tu manipules une variable, c'est elle qui est l'élément essentiel.
Justement, en math, combien de fois tu as écris sur ta copie 0 = x plutôt que x = 0 ? Si tu écris x = 0 (avec x dans le terme de gauche, donc), c'est parce que ce qui t'intéresse, c'est la variable. C'est ce que tu mentionnes en premier. Si je te donne une variable, tu peux avoir son contenu, ici 0. Mais si je te donne un 0, il y a une infinité de variables qui pourraient avoir cette valeur. Ce n'est pas bijectif. Là on est dans le cas de l'assignation et pas dans le test, mais c'est tellement similaire que même si l'opérateur de comparaison est commutatif, dans les faits, la partie qui m'intéresse je veux l'écrire en premier, donc à gauche de l'opérateur.
Bin non, je ne veux pas. C'est changer le mode de pensée du développeur pour contourner une difficulté du langage. C'est à la machine de s'adapter à l'humain, pas l'inverse. Le code machine, c'est pour l'ordinateur, moi je suis un humain et je veux du code lisible, sans avoir à m'adapter à une méthode de contournement bidon.
Le code est avec des noms d'instructions en anglais, pour être quasiment lu comme de l'anglais,
Pour la même raison foireuse. C'est aux compilateurs ou analyseurs statiques de t'avertir des tournures dangereuses.
[^] # Re: Yoda ?
Posté par barmic 🦦 . Évalué à 2.
C'est un super mauvais exemple : tu as des langages qui inversent l'affectation. Le premier qui me vient en tête c'est TI-Basic (https://fr.wikipedia.org/wiki/TI-Basic).
Il y a un moment où il faut travailler la plasticité de son cerveau aussi. Se créer des biais et passer temps à les maintenir ça n'a rien de sain.
Si ta comparaison est faite via une fonction du type
a.equals(b)
ouequals(a, b)
, tu te sent perdu ?https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Yoda ?
Posté par liberforce (site web personnel) . Évalué à 2. Dernière modification le 12 novembre 2019 à 19:01.
Et ? Le fait qu'un langage implémente cela dans sa syntaxe validerait cette approche. Dans ce cas les créateurs du brainfuck ont validé plein de choses. Ensuite il y a une différence entre la syntaxe d'un langage (obligatoire) et une convention qu'on est libre d'adopter ou pas.
C'est cette inversion d'opérandes qui est un bias pour compenser la mauvaise utilisation du langage…
Toi qui prenais l'exemple des Texas Instrument, j'ai utilisé une HP48 et utilisé en notation polonaise inversé (RPN). C'est une approche avec laquelle j'ai complètement adhéré (et à laquelle j'adhère toujours), et là pour le coup c'est vraiment une feature qui mérite le changement de mode de raisonnement.
Mais là on parle d'une convention comme méthode de contournement pour un problème pour lequel le compilo remonte déjà un warning, et un -Werror te remontera donc obligatoirement tous les cas problématiques:
Le compilo te suggère de doubler les parenthèses pour expliciter le fait que oui, tu souhaites utiliser le résultat de cette affectation comme valeur pour ton test. Pas besoin de plus.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
# Python se rapproche du Perl ?
Posté par Philippe F (site web personnel) . Évalué à 10.
Je suis un grand fan de Python mais je suis légèrement réservé sur les évolutions du langage ces dernières années.
Quand j'ai commencé le Python, on était en 1.5.2 , et n'importe quel programmeur C, C++ ou Java pouvait lire du code Python sans jamais en avoir vu avant. Ces dernières années, on a fait évoluer la syntaxe de Python pour obtenir des possibilités très intéressantes, mais la syntaxe devient de moins en moins lisible.
Allez, je me lance pour un concentré de truc imbitable:
Est-ce que quelqu'un qui n'a jamais fait de Python peut me dire à quoi ça correspond ? A mon avis non. Même moi, j'ai du mal quand je vois ça. Pourtant, c'est tout à fait légitime en Python 3.8 . Et si on enlève le
t:=
à la fin et le/
dans l'appel de fonction, ça marche même en Python 3.7 .Python à ses débuts avait notamment pris soin d'éviter les opérateur trop cryptiques pour les remplacer par des mot-clés (typiquement "and" au lieu de "&&", …). C'était une caractéristiques distinctives de Perl à l'époque qui raffolait des opérateurs imbitables et illisibles à base de caractères imprononçables. Ça soulageait aussi ma vision astigmate.
Je regrette que le "power Python" ressemble de plus en plus à du Perl.
Si j'écris du Python qui doit être relu par mes collègues, je suis attentif à éviter toutes les syntaxes puissantes car j'ai besoin qu'ils comprennent et soient en mesure de modifier mon code.
On est en train de prendre la route du C++, ou deux personnes peuvent toutes les deux prétendre savoir coder en C++ et n'avoir que 10% de savoir en commun !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Python se rapproche du Perl ?
Posté par jihele . Évalué à 8.
Je trouve aussi.
J'ai pas le temps, mais ça donnerait envie de relire les échanges pour comprendre pour pas
as
.Peut-être que Devuan pourrait distribuer un fork de Python qui utilise
as
.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 16 octobre 2019 à 14:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Python se rapproche du Perl ?
Posté par Victor STINNER (site web personnel) . Évalué à 9.
La PEP 572 liste les différentes alternatives proposées et donc rejetées.
https://www.python.org/dev/peps/pep-0572/#alternative-spellings
[^] # Re: Python se rapproche du Perl ?
Posté par bayo . Évalué à 5.
J'ai beau lire, je trouve ça triste. Compliquer un langage simple, pour fluidifier à la marge 2 pauvres cases d'usage, qui avec deux lignes feront toujours l'affaire et seront plus flexible à travailler et à comprendre.
[^] # Re: Python se rapproche du Perl ?
Posté par liberforce (site web personnel) . Évalué à 4. Dernière modification le 06 novembre 2019 à 17:32.
C'est surtout que l'exemple initial est discutable:
https://www.python.org/dev/peps/pep-0572/#the-importance-of-real-code
Avec ce code "amélioré", on se retrouve avec autant de if/else imbriqués et donc de niveaux d'indentation qu'on a de motifs…
Pour éviter l'indentation, j'aurais fait une sous-fonction et fait du early return:
Après j'ai pas de soucis avec la nouvelle syntaxe que je découvre aujourd'hui, mais il y a peut être des bonnes pratiques ou avertissement issus d'analyseurs statiques de code qui auraient pu aider à corriger ce problème plutôt que le langage lui même.
[^] # Re: Python se rapproche du Perl ?
Posté par bayo . Évalué à 3.
Oui effectivement,
Le seul cas pratique, j'avoue malgré moi même, c'est pour les boucles
En lieu et place de ce que j'ai tendance à écrire :
Pas tant pour le nombre de ligne, mais plutôt pour la sémantiquement. Ça me pique toujours un peu d'écrire une boucle "infinie". Je pouvais vivre avec :-)
[^] # Re: Python se rapproche du Perl ?
Posté par lym . Évalué à 2.
Mouais… Cela doit dépendre d’où l'on vient car le := me semble pour ma part plus clair.
Visiblement, les discutions ont été agitées au point de tuer le père! En arriver là, vu de dehors, ramène un peu à Sigmund.
[^] # Re: Python se rapproche du Perl ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Le
/
dans les arguments est une possibilité du langage qui peut être pratique mais qui n'a pas forcément (et ne devrait pas à mon avis) à être utilisé souvent.Je vois 2 cas principaux où c'est utile et ça peut empêcher des problèmes:
**kwargs
, et le jour où ça arrive, on est bien content d'avoir cette syntaxe.De toute façon, comme le rappelle le zen de Python (
import this
), « Explicit is better than implicit. »: ces syntaxes sont à utiliser quand elle sont vraiment nécessaires, et dans les autres cas il vaut mieux quelques lignes de plus pour rendre le code plus lisible.Quelqu'un qui veut rendre un code illisible y arrivera toujours, Python ou pas.
[^] # Re: Python se rapproche du Perl ?
Posté par flan (site web personnel) . Évalué à 5.
J'ai la même réaction. J'imagine qu'on ne gagne pas des masses sur les performances, et on perd en lisibilité ce qu'on gagne en écriture (alors qu'on écrit une seule fois mais on lit plusieurs fois : c'est plutôt le second qu'il faut optimiser).
[^] # Re: Python se rapproche du Perl ?
Posté par raum_schiff . Évalué à 3.
Perl n'a pas d'arguments nommés, tous ces arguments sont positionnels et finissent dans @_.
Pour contourner le problème on peux passer un hash en référence.
Bon en fait je trouve :
Très moche (pour du Python) … tout comme les opérateurs *args et **kwargs, mais vu qu'il n'y a pas de préfixe de variable en python pour les typer ad-hoc, ils ont choisi de flaguer les arguments et en plus de rajouter un séparateur '/' arbitraire.
Dommage.
[^] # Re: Python se rapproche du Perl ?
Posté par tibodit . Évalué à 3.
Intrigué par le concentré de truc imbitable et supposant que c'est valide, peut-on avoir une petite explication ?
[^] # Re: Python se rapproche du Perl ?
Posté par Philippe F (site web personnel) . Évalué à 10.
Avec plaisir. Alors, l'explication de texte:
Pour ce qui des arguments de la fonction
f
:/
comme epxliqué dans la dépêche implique quea
peut être passé uniquement en paramètre positionnel,d
peut être passé un paramètre positionnel ou par mot-clé ete
ne peut peut être passé que par mot-clé.Concrètement:
La partie
l: Dict[int,int]
, c'est juste pour le sport. Ça déclare une variable annotée en tant que dictionnaire avec des clés de type entier et des valeurs de type entier. Pour rappel, les annotations sont ignorées par Python, il faut lancer un outil externe comme mypy pour en tirer quelque chose.La nouvelle syntaxe permettant du unpacking dans les dictionnaires:
{5:9, **dict}
, cela crée un nouveau dictionnaire, avec d'une part une clé5
associée à la valeur9
, et toutes les autres clés-valeurs sont piochées dans le dictionnaire qui suit le**
.Les dict comprehensions
{v: v**2 for v in d }
, cela crée un dictionnaire dont les clés serontv
et associées aux valeurv**2
c'est à dire v puissance 2. La valeurv
est piochée en parcourant les clés du dictionnaired
.On rajoute ensuite un filtre sur les valeurs qu'on pioche dans d via
if v%2
, en ne gardant que celles qui vérifientv%2
est vrai, c'est à direv%2
différent de zéro, c'est à dire les nombres impairs. On a donc l'explication du{ v: v**2 for v in d if v%2 }
.Le
(t:=v%2)
permet de stocker la valeurv%2
dans une variablet
, c'est la nouveauté du Python 3.8 expliquée dans la dépêche.En pratique:
[^] # Re: Python se rapproche du Perl ?
Posté par lolop (site web personnel) . Évalué à 3.
Dans l'exemple de
:=
, ça serait mieux sit
était réutilisé dans l'expression (à ce moment on ne calcule qu'une fois):(note: pas testé, pas encore installé la version)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Python se rapproche du Perl ?
Posté par Philippe F (site web personnel) . Évalué à 4.
Il faut absolument garder le
**2
, sinon, ça ne pique pas les yeux ![^] # Re: Python se rapproche du Perl ?
Posté par ted (site web personnel) . Évalué à 1.
J'ai compris plus ou moins le fonctionnement, mais pas l'intérêt. Quel est l'intérêt d'obliger à ce qu'un paramètre soit positionnel exclusivement?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Python se rapproche du Perl ?
Posté par GuieA_7 (site web personnel) . Évalué à 5.
C'est rarement utile, mais ça arrive que la sémantique des arguments change avec leur nombre et ordre. Par exemple la classique fonction
range()
ne prend pas d'arguments par mot-clé ; ça va pouvoir être formalisé plus proprement dans sa signature avec Python 3.8.C'est pratique aussi pour les IDE qui extraient un fichier .py représentant l'interface d'un module écrit en C dans lequel les fonctions utilisent uniquement l'ordre des arguments.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Python se rapproche du Perl ?
Posté par Grunt . Évalué à 2.
Je me retrouve beaucoup dans ton commentaire.
Chaque fois que je cherche comment faire quelque chose de "compliqué" en python, je tombe sur une question similaire à la mienne, et toujours un petit malin qui répond "à partir de la version 3.X.X, tu peux faire ça" suivi d'un code imbitable (donc impossible à adapter) comme ton exemple.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Arguments exclusivement positionnels ?
Posté par ß ß . Évalué à 3.
Je ne comprend pas ce qui fait que
def f(a, /, b):
implique que a ne peut pas être nommé.Pour dire qu'un argument doit être exclusivement positionnel, faut-il le suffixer par
, /
? Comme si on attendait un argument/
?Est-ce qu'on peut trouver de la documentation sur cette feature ?
Je n'en ai pas trouvé après une brève recherche, mais j'imagine que c'est normal si c'est une nouvelle feature pas encore utilisée et discutée uniquement dans les ml de dev python.
[^] # Re: Arguments exclusivement positionnels ?
Posté par Thomas Douillard . Évalué à 5.
Tous les arguments qui précèdent un "/" dans la liste des arguments sont exclusivement positionnels. C’est à dire si j’ai bien compris que leur valeur n’est accessible que par la variable locale ("a" ici) qui leur correspond.
Si tu cherches un "a" comme clé du dictionnaire des arguments, sa valeur ne sera jamais celle du "a" positionnel, ce qui libère la clé "a" pour autre chose éventuellement.
[^] # Re: Arguments exclusivement positionnels ?
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Ca permet aussi d'éviter ce problème :
Pas de soucis avec / :
# Walrus
Posté par Joalland . Évalué à 2.
C'est marrant, j'ignorais que le mot "Walrus" désignait autre chose que le navire du capitaine Flint.
Merci pour la dépêche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.