Journal pas d'inference de type a la ocmal en python

Posté par  (site web personnel) .
Étiquettes : aucune
0
3
fév.
2005
pour l'instant.

C'est un sujet qui me tarabustait depuis pas mal de temps. Pourquoi python ne serait-il pas capable de faire de l'inference de type et de relever des erreurs evidentes qui sont relevees dans d'autres langages a la compilation ? Je me disais que pychecker pourrait faire qqch de similaire.

Pour mettre dans le contexte:
def f1( a ): return a + 1

def f2():
b = f1( 3 ) # ca va marcher
c = f1( [] ) # ca va pas marcher

# autre exemple
def f3(a):
if a is None: b = "toto"
else: b = 1
b = b + 1 # ne marche que si a != None, sinon, ca plante

J'ai pose la question sur ocaml et sur comp.python. Bon, la reponse est arrivee. En fait, en ocaml, il y a un typage fort des variables, qui fait qu'elles ne changent pas de type. A partir de ca, on peut faire des maths et trouver les variables qui sont mal typees.

En python, le typage est dynamique donc une variable peut prendre plusieurs types au cours de sa vie. A cause de cela, on peut pas faire tourner des algos de deduction de type, il y a trop de variantes possibles.

En fait, si le typage en python etait statique (impossible de changer le type d'une variable, mais possibliite de changer sa valeur), ca pourrait marcher.

Des nouveaux projets comme pypy permettront probablement de faire des interpreteurs python avec des proprietes particulieres, comme d'imposer un typage statique, optimiser du code a la volee (facon psyco mais en plus intelligent), etc.

Donc, si je veux avancer, il faut contribuer a http://codespeak.net/pypy/(...)

  • # OCaml & python ont vraiment des approches et possibilités différentes...

    Posté par  (site web personnel) . Évalué à 7.

    Une des grandes forces de python est sa capacité d'instrospection, réflexivité et auto modification. Typiquement on peut tout à fait imaginer des variables dont le type dépende de données disponibles uniquement à l'exécution. Cela peut par exemple aider pour certaines partie d'un parseurs. Il y a aussi dans la même veine les 'metaclass' qui permettent de générer des classes à la volée. Les cas où c'est effectivement réellement utiles ne manquent pas, mais il faut avoir un peu d'habitude pour bien y saisir souvent ...

    Bien sûr, tout cela est contournable et il possible de s'en passer (MetaOCaml par exemple doit implémenter des possibilités un peu similaires); mais ce qu'on gagne, dans un certain sens, en performance ou en 'sureté' (vaste problème...), on le perd également beaucoup en souplesse.

    Si tu continue à faire du python, essaye d'exploiter à fond ses possibilités, ça change pas mal d'approches pour beaucoup de problèmes (ce qui est souvent appellé "the pythonic way"). On peut souvent exprimer un problème de manière bien plus concise (moins de redondance notamment) sans pour autant perdre trop en lisibilité. Un fil de news intéressant pour python : http://www.pythonware.com/daily/(...)

    Pour ce qui concerne psyco je te conseille de lire un peu les articles donnés sur le site avant de chercher à faire un truc "plus intelligent"; tu verras, c'est déjà assez subtil :) (en plus tu verras d'autres raisons qui font que python n'est pas vraiment compilable au sens classique du terme).

    Accessoirement, le typage statique semble faire couler pas mal d'encre dans la communauté python actuellement; car s'il est pas possible (en l'état actuel) de faire de l'inférence de type, il est pourrait être intéressant de spécifier à certains endroit explicitement le type, pour des question de clarté de code, de sureté ou d'optimisation.

    • [^] # Re: OCaml & python ont vraiment des approches et possibilités différente

      Posté par  (site web personnel) . Évalué à 4.

      Accessoirement, le typage statique semble faire couler pas mal d'encre dans la communauté python actuellement


      Alors que dans la majorité des cas, un typage statique est demandé par "habitude", parce que les autres langages utilisent ça.

      En python, on préfère utiliser le duck typing : si ça marche en canard et que ça fait "CO1N !", on le traite comme un canard (non non, pas comme une moule). Un raisonnement assez proche de celui mis en place avec l'inférence de type. Ce qui est intéressant, ce sont les capacités de ton objet, pas son type.

      Ainsi, pour le premier exemple, f1 ne demande pas un entier en argument, mais n'importe quel "truc" auquel on peut ajouter un entier. Un entier ou un long, un float, un Decimal en python2.4, un complexe, ou n'importe quelle classe définie par moi et qui accepte qu'on lui ajoute 1.

    • [^] # Re: OCaml & python ont vraiment des approches et possibilités différente

      Posté par  . Évalué à 1.

      Oh un Palats :)

      Merci pour ton intervention d'une clarté appréciable... Si t'as d'autres liens de la même qualité sur Python, n'hésite pas à les poster, ça fait toujours du bien !

    • [^] # Re: OCaml & python ont vraiment des approches et possibilités différente

      Posté par  (site web personnel) . Évalué à 0.

      "Une des grandes forces de python est sa capacité d'instrospection, réflexivité et auto modification."

      Tiens, ça me fait penser au Prolog ça, langage injustement méconnu ^^

      Ceci dit, je refais un peu de PHP en ce moment après une longue période Java, et le typage dynamique également présent dans ce langage me fait finalement perdre pas mal de temps en déboguage. Pour que ce typage dynamique ait un vrai intérêt, il faut vraiment l'utiliser à fond pour faire un code concis et peu sujet aux bugs.

    • [^] # Re: OCaml & python ont vraiment des approches et possibilités différente

      Posté par  (site web personnel) . Évalué à 4.

      > Une des grandes forces de python est sa capacité d'instrospection, réflexivité et auto modification. Typiquement on peut tout à fait imaginer
      > des variables dont le type dépende de données disponibles uniquement à l'exécution.

      Je pense que ce type d'exemple donne du code particulierement complexe a comprendre et a maintenir. Dans certains cas, c'est pratique, mais dans la plupart, c'est plutot risque.

      Faut voir que si tu leves une exception dans ton code, tu es "foutu", c'est comme si tu avais fait un segfault.

      Un des problemes de python, c'est que sur un gros programme, tu as beaucoup de chances d'avoir dans un coin un fonction qui te renvoie un type qui va faire planter tout ton programme. J'ai eu le cas il y a quelques semaines avec un stagiaire qui m'a code une fonction renvoyant une liste ou bien None quand il n'y avait rien a renvoyer. Le none a foutu la merde, alors que renvoyer une liste vide serait passe sans probleme.


      En s'appuyant sur un typage fort, statique mais non declaratif ni impose (c'est a dire comme en ocaml, avec juste de l'inference de type), on peut avoir plus de certitudes sur la fiabilite d'un programme, ce qui me parait un eujeu fondamental du developpement logiciel de nos jours.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.