Discussion :

[Mr ZEE]

Bonjour,

Code :

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

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

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

Code :

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

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

Et 12 sur :

Code :

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

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 ?

[wiztricks]

Salut,

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

[Sve@r]

Bonjour

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 python :

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

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

[wiztricks]

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

[Sve@r]

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?

[wiztricks]

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?)

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

Non je dirais qu'on écrira:

Code :

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

1
2
3
4
def concat(a, b):
	assert isinstance(a, str)
	assert isinstance(b, str)
	return a + b

ou (exclusif)

Code :

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

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

[Sve@r]

on évite de faire une mixture.

Compris

[fred1599]

Hello,

Bonjour

assert

Code python :

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

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 :

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

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 :

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

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'

[N_BaH]

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

[Sve@r]

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...

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

[fred1599]

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 :

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

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 :

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

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:

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...

[wiztricks]

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

[fred1599]

Hello,

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

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.