Typage statique (fort?) pour Python3.10 et +

Bonjour,

Code:

---

1 2	def concat(a: str, b: str) -> str: return a + b

---

Cette fonction renvoie la chaîne de caractères "48" sur :

Code:

---

print(concat('4','8'))

---

Et 12 sur :

Code:

---

print(concat(4,8))

---

Existe-t-il un moyen d'obliger python3 à générer un warning à l'écriture et/ou (à défaut et au moins) une erreur à l'exécution ?

Salut,

Citation:

---

Envoyé par Mr ZEE

Existe-t-il un moyen d'obliger python3 à générer un warning à l'écriture et/ou (à défaut et au moins) une erreur à l'exécution ?

---

Des outils comme mypy vont vérifier que le typage statique est respecté en analysant le code avant exécution.
Tout ça est bien expliqué dans la documentation du module typing (qui comprend de nombreux renvois).

- W

Bonjour

Citation:

---

Envoyé par Mr ZEE

Existe-t-il un moyen d'obliger python3 à générer un warning à l'écriture et/ou (à défaut et au moins) une erreur à l'exécution ?

---

assert

Code:

---

1 2 3 4

def concat(a: str, b: str) -> str: assert isinstance(a, str) assert isinstance(b, str) return a + b

---

L'avantage c'est qu'en mode dev c'est pris en compte mais quand le truc est vérifié/finalisé, il te suffit d'exécuter en mode optimisé et les assert sont alors ignorés

Citation:

---

Envoyé par Sve@r

L'avantage c'est qu'en mode dev c'est pris en compte mais quand le truc est vérifié/finalisé, il te suffit d'exécuter en mode optimisé et les assert sont alors ignorés

---

C'est ce qu'on faisait "avant"... Et je ne suis pas sûr que mélanger une vérification dynamique soit "en ligne" avec le typage statique utilisé.

- W

Citation:

---

Envoyé par wiztricks

C'est ce qu'on faisait "avant"

---

Et "avant" c'est synonyme de "has been"? Les outils comme mypy c'est bien pour checker un code "simple", style j'appelle concat(1, 2) avec des valeurs à la con. Mais que se passe-t-il si les valeurs proviennent d'un flux externe style bdd?

Citation:

---

Envoyé par Sve@r

Mais que se passe-t-il si les valeurs proviennent d'un flux externe style bdd?

---

Les échanges se font via des tuples de... qu'on peut décorer avec un typage statique (comment fait-on avec C++, Java?)

Citation:

---

Envoyé par Sve@r

Et "avant" c'est synonyme de "has been"?

---

Non je dirais qu'on écrira:

Code:

---

1 2 3 4

def concat(a, b): assert isinstance(a, str) assert isinstance(b, str) return a + b

---

ou (exclusif)

Code:

---

1 2	def concat(a: str, b: str) -> str: return a + b

---

ie. on utilise le typing avec les outils qui sont autour... et on évite de faire une mixture.

- W

Citation:

---

Envoyé par wiztricks

on évite de faire une mixture.

---

Compris

Hello,

Citation:

---

Envoyé par Sve@r

Bonjour

assert

Code:

---

1 2 3 4

def concat(a: str, b: str) -> str: assert isinstance(a, str) assert isinstance(b, str) return a + b

---

L'avantage c'est qu'en mode dev c'est pris en compte mais quand le truc est vérifié/finalisé, il te suffit d'exécuter en mode optimisé et les assert sont alors ignorés

---

Alors, tout à fait en accord avec @wiztricks, mais j'ai un peu de temps pour développer un avis sur la question.

assert est utilisé pour les tests (unitaires et intégrations) principalement.

Il est conseillé généralement sur son code d'interrompre le programme à l'aide d'un raise quand un type d'objet fourni en paramètre de la fonction ne correspond pas au besoin.
Une fois la fonction créée, en prenant en compte les différentes erreurs possibles, on crée des tests unitaires qui permettent de vérifier tout ça.

Un exemple :

Code:

---

1 2 3 4 5

def concat(a: str, b: str) -> str: if not isinstance(a, str) and not isinstance(b, str): raise TypeError("a and b must be strings")   return a + b

---

et les tests unitaires (avec pytest)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

import pytest from module import concat   def test_concat_with_bad_parameter_a(): with pytest.raises(TypeError): concat(1, 'a')   def test_concat_with_bad_parameter_b(): with pytest.raises(TypeError): concat('a', 1)   def test_concat_with_bad_parameters(): with pytest.raises(TypeError): concat(1, 2)   def test_concat(): assert concat('a', 'b') == 'ab'

---

cela ne devrait-il pas être not or not ? car l'un des deux paramètres pourrait bien être un str, non ?

Citation:

---

Envoyé par fred1599

Il est conseillé généralement sur son code d'interrompre le programme à l'aide d'un raise quand un type d'objet fourni en paramètre de la fonction ne correspond pas au besoin.

---

Oui mais un test/raise sera fait tout le temps, y compris en prod quand le truc est finalisé. Et, comme le disait Nedry dans Jurassic Park avant qu'il se fasse violer par sais plus quel bestiau (celui qui a une colerette et qui crache du venin), ça bouffe des cycles inutilement...
Alors qu'un assert, une fois le code finalisé, est alors shunté en mode prod...

Citation:

---

Envoyé par N_BaH

cela ne devrait-il pas être not or not ? car l'un des deux paramètres pourrait
bien être un str, non ?

---

Hé oui. Encore une fois la loi de De Morgan not(A et B)=not(A) ou not(B) a été foulée aux pieds de la méconnaissance :mouarf:

Citation:

---

Envoyé par N_BaH

cela ne devrait-il pas être not or not ? car l'un des deux paramètres pourrait bien être un str, non ?

---

Ce qui est le cas dans mes tests non ? Et pourtant mes tests passent... car naturellement la concaténation d'un entier et d'une chaîne de caractères provoque déjà un TypeError.
Dans ce cas il aurait fallu vérifier dans mes tests le message d'erreur retourné

Code:

---

1 2 3 4 5

def test_concat_with_bad_parameter_a(): with pytest.raises(TypeError) as err: concat(1, 'a')   assert str(err.value) == "a and b must be strings"

---

J'ai été vite en effet dans l'écriture de mon code exemple effectivement, mais c'est plus pour montrer le principe, je modifie donc

Code:

---

1 2 3 4 5 6

def concat(a: str, b: str) -> str: if not isinstance(a, str) or not isinstance(b, str): raise TypeError("a and b must be strings")     return a + b

---

EDIT:

Citation:

---

Oui mais un test/raise sera fait tout le temps, y compris en prod quand le truc est finalisé. Et, comme le disait Nedry dans Jurassic Park avant qu'il se fasse violer par sais plus quel bestiau (celui qui a une colerette et qui crache du venin), ça bouffe des cycles inutilement...
Alors qu'un assert, une fois le code finalisé, est alors shunté en mode prod...

---

Privilégier la performance à la sécurité est un risque qu'on peut prendre mais que je ne prendrai jamais... L'environnement de développement peut être fonctionnel, ce n'est pas pour autant qu'en production ça sera le cas, en tout cas on ne peut l'assurer à 100% avec l'utilisation de assert, car son travail s'arrête à l'environnement de dev. Par contre, raise fonctionnera quelque soit l'environnement...

Citation:

---

Envoyé par fred1599

Privilégier la performance à la sécurité est un risque qu'on peut prendre mais que je ne prendrai jamais...

---

Dans le cas particulier, le a + b natif plante déjà en TypeError si a et b ne sont pas du même type avec un message d'erreur explicite: un test fait via assert ou sans plantera avec un autre message d'erreur.

- W

Hello,

Citation:

---

Envoyé par wiztricks

Dans le cas particulier, le a + b natif plante déjà en TypeError si a et b ne sont pas du même type avec un message d'erreur explicite: un test fait via assert ou sans plantera avec un autre message d'erreur.

- W

---

Oui c'est ce que j'indique dans mon précédent post

Citation:

---

Ce qui est le cas dans mes tests non ? Et pourtant mes tests passent... car naturellement la concaténation d'un entier et d'une chaîne de caractères provoque déjà un TypeError.

---