Forcer le type des paramètres d'une fonction

Version imprimable

09/08/2010, 11h30
Teocali

Forcer le type des paramètres d'une fonction

Bonjour,

après quelques années sans y toucher, je me remets a Python et tente desperement de combler mes trous de mémoire.

L'un de ces trous parmi les plus gênant est que je suis incapable de me rappeler s'il est possible de forcer le type des paramètres d'une fonction (ergo, si je demande un entier et que l'utilisateur me fourni une chaine, vlan, TypeError dans sa face) et si oui, comment ?

De même, si c'est possible, est-ce également possible de demander une liste d'arguments du même type, via le très pratique opérateur '*' ?

Parce que bon, je peux toujours faire le teste, mais ça peut toujours être utile a savoir.

Bien entendu, j'ai cherché dans le forum, mais impossible de trouver quoique ce soit qui y fasse référence (la fonctionnalité de recherche du forum n'est pas vraiment au point ><)

Cordialement,
Teocali
09/08/2010, 13h27
kango
bonjour,

voici par exemple une fonction qui somme tous les arguments:
Code:

1 2 3 4 5 6 7 8 def sumint(*values) s = 0 for v in values: try: s += int(v) except ValueError: raise TypeError return s
si tu veux une fonction qui travaille vraiment avec des arguments typés, écris la fonction en C et fais en une extension Python :)
09/08/2010, 14h14
Teocali

Ok, donc, c'est confirmé, il n'y a pas de mecanisme built-in en Python pour ce genre de truc. C'est noté. merci de ton aide.

Cordialement,
Teocali
09/08/2010, 16h32
eyquem

Je n’avais pas compris ta question parce que tu emploies le terme de “paramètre“ au lieu d’ “argument“.

En fait ta question n’a pas spécialement à voir avec les paramètres d’une fonction, ni avec les arguments.

Elle consiste à se demander de façon général s’il existe un forçage de type en Python comme dans d’autres langage pour rendre possible une évaluation d’expression qui ne l’est pas au départ pour raison de types différents en confrontation.

La réponse est simple si on connaît le data model de Python:

- dans d’autres langages, la représentation binaire des données est portée par des variables et ce sont les variables qui sont typées.
- en Python, la représentation binaire des données est portée par des objets et un objet Python est quelque chose de très monolithique:

Every object has an identity, a type and a value. An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. (...) An object’s type is also unchangeable. (...) The value of some objects can change.

http://docs.python.org/reference/dat...lues-and-types

Pour ce qui est des paramètres d’une fonction, ils ne sont pas perturbés par le type des arguments qu’ils reçoivent. C’est après, une fois dans la fonction, que les arguments passés risquent d’être incompatibles avec d’autres objets dans certaines opérations.

En résumé, Python n’est pas un langage permissif qui permette à des calculs contre nature de se faire quand même en changeant des types à l’aveuglette.
C’est au développeur de concevoir un algorithme qui évite ces collisions ou qui les gère.
09/08/2010, 16h41
Zavonen

Si tu veux faire du type-checking automatique en python, le mieux est d'utiliser un décorateur. voici un exemple:
http://code.activestate.com/recipes/...ing-decorator/
et un autre:
http://kedeligdata.blogspot.com/2009...in-python.html

Voici une autre solution, moins complexe, mais pas forcément aussi pratiques d'emploi que celles citée par Zavonen :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
>>> def checkType(t,*args):
	if not all([type(x)==t for x in args]):
		raise TypeError
 
 
>>> def test(a,b,c):
	checkType(int, a,b,c)
	print "Ok"
 
 
>>> test(1,"a",2)
 
Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    test(1,"a",2)
  File "<pyshell#12>", line 2, in test
    checkType(int, a,b,c)
  File "<pyshell#8>", line 3, in checkType
    raise TypeError
TypeError
>>> test(1,2,3)
Ok

la fonction type() est là pour ça :)
Et voici une version permettant plusieurs types pour une ou plusieurs variables:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
>>> def checkType(types,*args):
	'''types <-- (type) or (list|tuple of types)
        args <-- arguments to check'''
	if type(types) in (list,tuple):
		if not all(any(type(x)==y for y in types)for x in args):
			raise TypeError
	else:
		if not all(type(x)==types for x in args):
			raise TypeError
 
 
>>> def test(a,b,c):
	checkType(int, a,b,c)
	print "Ok"
 
 
>>> test(1,"a",2)
 
Traceback (most recent call last):
  File "<pyshell#20>", line 1, in <module>
    test(1,"a",2)
  File "<pyshell#19>", line 2, in test
    checkType(int, a,b,c)
  File "<pyshell#17>", line 3, in checkType
    raise TypeError
TypeError
>>> def test(a,b,c):
	checkType((int,str), a,b,c)
	print "Ok"
 
>>> test(1,"a",2)
Ok
 
>>> def test2(a,b,c):
	checkType(int, a,b,c)
	print "Ok"
 
>>> test2(1,3,2)
Ok
>>> def test3(*a):
	checkType(int, *a)
	print "Ok"
 
 
>>> test3(1,'a')
 
Traceback (most recent call last):
  File "<pyshell#34>", line 1, in <module>
    test3(1,'a')
  File "<pyshell#33>", line 2, in test3
    checkType(int, *a)
  File "<pyshell#29>", line 5, in checkType
    raise TypeError
TypeError
>>> test3(1,2,3)
Ok

13/08/2010, 19h57
Zavonen

Citation:

Every object has an identity, a type and a value. An object’s identity never changes once it has been created; you may think of it as the object’s address in memory. (...) An object’s type is also unchangeable. (...) The value of some objects can change.

Bon d'accord, ça c'est la 'bible'. Il n'empêche que le transtypage automatique existe même en python pour les types primitifs. Il y a des automatismes pour transformer un int en float.
Par contre, ce comportement en python, est difficile à étendre aux objets fabriqués par l'utilisateur, pour la simple raison qu'à la différence de C++ python n'admet qu'un constructeur par objet.
En C++, par exemple, si un objet Truc peut être construit à partir d'une liste, on va écrire un constructeur (parmi d'autres) prenant une liste en argument. Par la suite, lorsqu'un opérateur attend en une certaine place un argument de type Truc, s'il trouve une liste L il fait une promotion automatique par appel du constructeur de Truc avec l'argument L.
Ce comportement, est à ma connaissance difficile à simuler avec python. Il est vrai que la couche objet est beaucoup plus élaborée en C++.
On peut néanmoins, traité au cas par cas, utiliser des décorateurs pour lister les types admissibles et se charger à la main des promotions dans les méthodes.
13/08/2010, 20h37
fred1599
On oublie isinstance ? Je ne l'ai pas vu deprecated sur le site officiel, en tout cas pour la version 2.7 python.

Bon eh bien je le met quand même ;)
Code:

1 2 3 4 >>> isinstance(12, int) True >>> isinstance("chaine", int) False
J'ai déjà vu qu'il n'était pas conseillé, je ne sais plus où. Cependant je l'ai pas vu sur le site officiel et n'a pas été supprimé dans la version 2.7

En ce qui me concerne je le trouve très pratique à mon niveau...

isinstance ne sera jamais supprimé (à moins qu'ils introduisent un autre mécanisme équivalent mais ça m'étonnerait). C'est trop fondamental à la façon dont la réflexion fonctionne en Python.

C'est vrai qu'il ne faut pas en abuser, et souvent une bonne conception orientée objet permet de s'en passer. Par exemple, au lieu de:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class A: .... class B: .... def f(x): if isinstance(x, A): # traitement A elif isinstance(x, B): # traitement B else: raise TypeError("x must be an instance of A or B")
il vaut mieux écrire:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class A: .... def f(self): # traitement A class B: .... def f(self): # traitement B def f(x): return x.f()
Mais quand on traite des types de bases (int, str, bool, ...), il est souvent malaisé de les sous-classer (pour y ajouter des méthodes) et dans ce cas il vaut mieux utiliser isinstance.

14/08/2010, 20h17
fred1599

Merci pour ces précisions dividee.

J'adore isinstance, je l'utilise beaucoup, et ça aurait été dommage s'il devait être supprimé. :ccool: