[gull] python2.5 et type(x)

[Daniel Cordey]

On Friday 01 August 2008 03:36:12 Philippe Strauss wrote:

> c'est plûtot particulier l'idée de ne pas distinguer une notion
> de typage avec une notion de classe d'objet,

Le cas de Python est peut-etre un peu particulier dans le sens ou tout est un 
objet (classe) en Python. La maniere dont ces objets sont concus est assez 
logique et cela permet de faire beaucoup de choses, tout en restant tres 
"propre". C'est donc assez different de l'infame bricolage de certains langages 
:-) 

En Python, une classe est definie dans un dictionnaire (qui est une classe...).

Toutefois, il existe bien une separation entre 'type' et 'class'. Entre autre, 
cela concerne les deux "built-in types" que sont les listes et les 
dictionnaires. De meme, une classe en definit pas un nouveau 'type'. C'est aussi 
pour pouvoir gerer les "heritages" de classes que la notion de "isinstance" a 
ete introduite. Ceci permet donc de determiner l'appatenance a une classe ou a 
ses derives. Il est donc possible de determiner l'appartenance a une classe de 
base pour une classe derivee; chose que l'on ne pourrait faire avec la notion de 
"type" qui est trop restrictive.

> mais bon, ca doit être cela un scripting langage.

Non, pas forcement. Un langage de "scripting" offre toutefois plus de 
"dynamisme" dans la gestion des objets, tout en conservant une certaine 
simplicite d'implementation. Un langage compile va etre nettement plus rapide, 
mais il imposera des contraintes de definitions specifiques. C'est le cas entre 
autre de la necessite de declarer les fonctions virtuelles en C++; chose qui 
n'est pas necessaire en Python.

> Doit pas aider les projets tentant de compiler du python
> vers c/c++.

Non, pas vraiment... SWIG permet deja de generer du code python et C/C++ 
permettant d'interfacer du code relogeable (*.o, *.so...) avec Python, et cela 
ne pose pas de problemes particuliers. La partie de C/C++ est ensuite compilee 
et permet d'etre chargee comme un module Python.

dc