Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue144:tutoriel1 [2019/05/03 07:33] – créée d52fr
+++ issue144:tutoriel1 [2019/05/08 10:27] (Version actuelle) – andre_domenech
@@ Ligne 1: / Ligne 1: @@
-First, I would like to congratulate Ronnie and the entire FCM staff for 12 years of FCM! I am honoured to be a small part of this wonderful publication.
+**First, I would like to congratulate Ronnie and the entire FCM staff for 12 years of FCM! I am honoured to be a small part of this wonderful publication.**
-Now on to the meat of this month's article...
+En premier lieu, je voudrais féliciter Ronnie et toute l'équipe du FCM pour les douze ans de la revue ! Je suis honoré de jouer un petit rôle dans cette publication.
+**Now on to the meat of this month's article...
 On April 4, 2019, PEP 570 (Python Enhancement Proposal) was accepted by the Python Steering Council, which includes Guido van Rossum. While it is unknown how soon it will be able to be implemented, the changes this brings suggest that we all should considering getting up to speed on the subject sooner than later.
@@ Ligne 8: / Ligne 10: @@
 and the original PEP can be found at...
+https://discuss.python.org/t/pep-570-python-positional-only-parameters/1078**
+Maintenant, rentrons dans le vif du sujet du mois.
+Le 4 avril 2019, la PEP 570 (Python Enhancement Proposal - Proposition d'amélioration de Python) a été acceptée par le conseil de pilotage de Python, dont Guido van Rossum fait partie. Alors que personne ne sait dans quel délai elle pourra être implémentée, les modifications qu'elle porte suggèrent que nous aurions tous à nous mettre à jour sur le sujet plus tôt que plus tard.
+Voici le lien vers la page officielle expliquant les modifications : https://www.python.org/dev/peps/pep-0570/#specification
+et la PEP originale peut être trouvée ici...
 https://discuss.python.org/t/pep-570-python-positional-only-parameters/1078
-Note: The information presented in this article is not meant to be an in-depth teaching article on Python programming using the PEP 570 syntax. It's intended to only give you a digested overview of what to expect, once it is implemented, and to encourage you to do more research into the subject on your own.
+**Note: The information presented in this article is not meant to be an in-depth teaching article on Python programming using the PEP 570 syntax. It's intended to only give you a digested overview of what to expect, once it is implemented, and to encourage you to do more research into the subject on your own.**
-Some background
+Note : L'information présentée dans cet article n'a pas pour objet d'être un article de formation approfondi sur la programmation en Python en utilisant la syntaxe de la PEP 570.  Il a simplement pour but de vous donner un aperçu pré-assimilé de ce à quoi s'attendre, une fois qu'elle est implémentée, et pour vous encourager à faire d'autres recherches par vous-même sur le sujet.
+**Some background
 Currently, Python uses what is called positional-or-keyword parameters. When we define a function, as we all know, we do it like this...
@@ Ligne 21: / Ligne 35: @@
 ...
-and for the most part, that is sufficient for most purposes. However, if someone wants to design a library, the number of parameters, placement and parameter names need to stay the same from release to release. Otherwise, it will break any software that calls it.
+and for the most part, that is sufficient for most purposes. However, if someone wants to design a library, the number of parameters, placement and parameter names need to stay the same from release to release. Otherwise, it will break any software that calls it.**
-The new syntax for function definitions would look like that shown above.
+Mise en situation
+Actuellement, Python utilise ce qui sont appelés des paramètres « positional-or-keyword » (à-position-fixe-ou-par-mot-clé). Quand nous définissons une fonction, comme nous le savons tous, nous le faisons comme ceci...
+def my_function(parm1=None, parm2, *args, **kwds):
+...
+et, la plupart du temps, c'est suffisant pour la majorité des besoins. Cependant, si quelqu'un veut concevoir une bibliothèque, le nombre de paramètres, leur position et les noms des paramètres doivent rester identiques de publication en publication. Autrement, cela plantera tout logiciel qui l'appelle.
+**The new syntax for function definitions would look like that shown above.
 Here are some important notes:
@@ Ligne 34: / Ligne 58: @@
 To show some of the ramifications of these changes, let's look at how we would access a function under the new requirements. Again, I borrowed the following lines from the PEP announcement...
-If we have only positional_only arguments, you would use a definition like this…
+If we have only positional_only arguments, you would use a definition like this…**
+La nouvelle syntaxe pour la définition des fonctions devrait ressembler à ce qui est présenté ci-dessus.
-def my_function(p1, p2, /):
+Voici quelques points importants :
+) Tous les paramètres après le / sont traités comme « positional-only » (à position fixe).
+) Si le / n'est pas spécifié dans la définition de fonction, cette fonction n'acceptera aucun argument à position fixe.
+) La logique à propos des valeurs optionnelles pour les paramètres à position fixe reste identique à celle des paramètres « positional-or-keyword ».
+) Une fois qu'un paramètre à position fixe est spécifié avec une valeur par défaut, les paramètres à position fixe ET ceux « positional-or-keyword » doivent aussi avoir des valeurs par défaut.
+) Les paramètres à position fixe qui n'ont pas de valeur par défaut sont des paramètres à position fixe EXIGÉS.
+Pour vous montrer quelques-unes des ramifications de ces changements, regardons comment nous pouvons accéder à une fonction avec ces nouvelles exigences. À nouveau, j'extrais les lignes suivantes de l'annonce de la PEP :
+Si vous n'avez que des arguments à position fixe, vous devriez utiliser une définition comme celle-ci :
+**def my_function(p1, p2, /):
     …
@@ Ligne 45: / Ligne 82: @@
     …
-However, if the parameter for “p1” has a default value, per condition #4, ‘p2’ would also need to have a default value assigned as well. So,
+However, if the parameter for “p1” has a default value, per condition #4, ‘p2’ would also need to have a default value assigned as well. So,**
-def my_function(p1 = None, p2, /):
+def my_function(p1, p2, /):
+    …
+C'est très proche de ce que nous utilisons actuellement, à l'exception des caractères « , / ». La première condition ci-dessus est satisfaite. Selon la condition 2, dans ce cas, le « / » doit être inclus ; sinon cela provoquera une erreur de syntaxe. L'exemple suivant montre un paramètre à position fixe dans une fonction où le second paramètre a une valeur par défaut égale à « None ». Ceci s'accorde avec la condition 3 ci-dessus.
+def my_function(p1, p2 = None, /):
+Cependant, si le paramètre « p1 » a une valeur par défaut, d'après la condition n° 4, « p2 » doit aussi avoir une valeur par défaut. Ainsi,
+**def my_function(p1 = None, p2, /):
     …
@@ Ligne 64: / Ligne 110: @@
 A final borrowing from the specification document is shown top right.
-That’s all I have this time, so I wish you a great upcoming month.
+That’s all I have this time, so I wish you a great upcoming month. **
+def my_function(p1 = None, p2, /):
+entraînerait une erreur de syntaxe.
+def my_function(p1 = None, p2 = None, /, p_or_kw):
+    …
+sera aussi invalide, car la condition n° 4 ci-dessus dit qu'une fois qu'une valeur par défaut a été définie pour un paramètre, tous les paramètres qui suivent, y compris les paramètres à position fixe ou ceux « positional-or-keyword », doivent aussi avoir une valeur par défaut. Ceci ne s'applique cependant pas aux paramètres « keyword_only » (seulement comme mot-clé). La déclaration suivante :
+def my_function(p1 = None, p2 = None, /, *, kw):
+sera parfaitement valable et bonne.
+Un dernier emprunt au document de spécification est présenté en haut à droite.
+C'est tout ce que j'ai pour cette fois-ci et je vous souhaite un excellent mois à venir.