Discussion :

[Sve@r]

Bonjour à tous

Je viens de découvrir que Python3 s'était enrichi d'une nouvelle syntaxe concernant les paramètres de fonctions: on peut leur rajouter le typage.

Par exemple en old syntaxe, une fonction s'écrira ainsi

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
def isPrime(n=1):
	if n == 1: return False
	if n == 2: return True
	for i in range(3, n, 2):
		if (n%i) == 0: return False
		if i > (n/i): return True
# isPrime()

En P3, on pourra l'écrire de la même façon ou bien de la façon suivante

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
def isPrime(n :int=1) -> bool:
	if n == 1: return False
	if n == 2: return True
	for i in range(3, n, 2):
		if (n%i) == 0: return False
		if i > (n/i): return True
# isPrime()

Alors déjà le typage n'engage à rien (la fonction indique qu'elle attend un int mais je peux lui passer une string sans que Python bronche). Mais j'aurais aimé avoir vos avis savoir ceux qui le mettent en pratique ou pas et les avantages que vous en retirez. Parce que mine de rien, c'est quand-même lourd à appliquer. Donc est-ce que ça vaut le coup ?

Merci à tous.

[VinsS]

Salut,

Ces annotations sont purement gratuites, c'est-à-dire qu'elles n'engagent que celui qui les utilise.

Elles n'ont d'utilité que pour certains programmes d'analyse de code. Essentiellement le logiciel mipy. Les autres tel que pylint s'adapteront peut-être.

L'introduction de ces annotations a fait l'objet d'un débat particulièrement houleux au sein des core devs de Python.

Sans qu'il ne l'aie dit explicitement, ce débat fut celui qui conduit Guido van Rossum à céder son pouvoir décisionnel aux mêmes core devs.

Personnellement, je trouve ces annotations très laides. Il s'agit là d'esthétique bien sur.

[Sve@r]

Merci de ta réponse.
Perso je pensais que c'était une espèce d'aide à l'écriture de code propre dans la programmation en équipe et à l'évolutivité (on voit rapidement ce qu'attend la fonction et ce qu'elle renvoie).

Question esthétique c'est évidemment subjectif. Pour l'instant j'ai aussi un peu de mal (j'ai passé mes quelques sources P3 dans cette syntaxe puis je les ouvre voir l'effet que ça me fait) mais peut-être qu'on peut s'y habituer.

En attendant les autres avis, merci à toi

[CosmoKnacki]

Ce qui serait malin avec ce genre de choses, c'est de pouvoir activer au choix un mode stricte qui déclencherait une exception lorsque le type n'est pas respecté (est-ce que ça existe?). Je ne suis pas étonné que cette "fonctionnalité" ait déclenché des débats houleux dans la mesure où l'on touche à l'identité même du langage (son coté simple, direct, sans fioritures).

[tyrtamos]

Bonjour,

J’apprécie la "souplesse" de Python, mais j'aurais aimé qu'il y ait une option possible de contrôle de type. Actuellement, à part pour faire de l'analyse de code statique comme le fait "mypy" (http://www.mypy-lang.org/), je ne vois pas l'intérêt de la nouvelle syntaxe puisqu'elle est complètement ignorée pendant l'exécution.

Cela m'a obligé à créer un décorateur qui fait du contrôle de type quand j'en ai besoin, comme je l'ai dit ici: https://www.developpez.net/forums/d1.../#post10803205.

C'est d'autant plus dommage que dans le cas de Cython, il faut ajouter les déclarations de types, mais avec une autre syntaxe, pour pouvoir compiler en C ou C++.

[fred1599]

Hello,

Mais j'aurais aimé avoir vos avis savoir ceux qui le mettent en pratique ou pas et les avantages que vous en retirez.

Je l'ai déjà utilisé et comme toi je trouve cette syntaxe lourde à appliquer. Perso, je n'en ai retiré aucun avantage ayant pas mal d'expériences dans ce langage, je m'explique...

Avantages:

1. Un débutant a tout intérêt à utiliser cette syntaxe sur des moyens et gros projets, ça lui évitera pas mal de bugs et l'obligera à organiser son code tout en contrôlant les types des arguments et de retour de fonctions.

Toi expérimenté, déjà tu t'organises préalablement au code, tu maîtrises les types, et fait tes contrôles de types quand nécessaire, tu utiliseras la force du duck typing en rendant tes fonctions plus flexibles sans risques car tu sais ce que tu fais. Ça reste là encore une discussion sur les responsabilités données aux développeurs python.

Inconvénients:

1. La maturité de cette syntaxe commence qu'à partir de la version 3.6, moi par exemple je suis encore à la version 3.5, version actuelle sur ma debian.
2. Je m'attendais à une optimisation des performances du langage, il en est rien ! En gros c'est du duck typing déguisé, avec des types vérifiés dynamiquement.
3. Le temps de développement plus long, tout cela pour dire qu'il y a une erreur de type, qui sera aussi renvoyé de la même manière par ton interpréteur
4. La vérification de type n'est pas la philosophie du langage, on préconise le try - except (duck typing). On peut parfois passer par isinstance, mais avec parcimonie.

Conclusion:

Je garde une veille technologique sur les différentes PEP concernant les annotations de type pour voir ce qui va en découler, surtout la partie performance...
Pour le reste, je prend la responsabilité de continuer à suivre la philosophie pour laquelle j'ai choisi ce langage.

[wiztricks]

Salut,

Perso je pensais que c'était une espèce d'aide à l'écriture de code propre dans la programmation en équipe et à l'évolutivité (on voit rapidement ce qu'attend la fonction et ce qu'elle renvoie).

C'est ainsi qu'il faut le voir avec en plus:

• une documentation "explicite" du type des paramètres,
• moins de cas de tests,
• un peu moins de code pour vérifier les types.

Je comprends le besoin de cela dans le cadre de gros projets et éventuellement comme aide à la maintenance et à l'évolution d'applications mais çà ne correspond pas à mon utilisation de Python (donc je ne m'en sers pas).

- W