Discussion :

[fred1599]

Ben non, que ce soit avec for ou enumerate, tu consommes l’itérateur

En effet je n'avais pas compris la question de cette façon là. En fait il veut avoir une autre méthode que next() pour son itérateur, et il y en a pas d'autres.

Bien vu mont29

[dividee]

Le but est d'analyser une formule dans un fichier. La première étape est de construire un arbre de syntaxe. J'ai décidé que pour rendre l'application plus propre je passerais par un module "Lexer". Il se construit grâce à un itérateur représentant le flux de donnée devant être analysé et, par le biais d'une méthode, renvoie des "Token", classe encapsulant une constante entière représentant un certain caractère (par exemple "/\" (ET logique) représenté par la valeur "1"). Ceci dans le but de dissocié l'interprétation graphique/syntaxique de l'interprétation sémantique de ce symbole. Le parser reçoit donc des Tokens et construira l'arbre syntaxique grâce à eux. C'est également lui qui sera chargé de construire la structure de donnée qui sera utilisée par la suite.

Donc une expression régulière ne conviendra pas pour ces raisons (confirmez svp.) :

1. Trop lente par rapport à un module spécialisé (j'accuse la généricité du module "re").
2. Ne permet pas de renvoyer une abstraction comme le "Token".
3. Donc un module "Lexer" serait quand même nécessaire.
4. Mais pour être utile, l'expression régulière devrait analyser l'entièreté de la formule d'abord. Donc on ne peut pas construire notre arbre de syntaxe en une seule passe.

Merci pour vos réponses.

C'est tout de même souvent des expressions régulières qui sont utilisées pour des "lexer" un peu complexes, comme par exemple dans (f)lex.

Mais si tu pars sur ce chemin, pourquoi réinventer la roue et ne pas utiliser une bibliothèque de parsing ? Il y en a déjà plein en Python (voir ici par exemple).

Pourquoi les performances du lexer/parser sont si importantes ? Le problème SAT est NP-complet, il me semble. Pour des formules un peu complexes, le temps de calcul sera de toute façon dominé par le solveur...

[Trademark]

Alors effectivement il existe des bibliothèques, je m'en doutais. Et il existe déjà même des solveurs qui sont déjà 100 fois plus performant que ce que je ne ferai jamais. Je pense que si j'avais voulu faire un solveur à titre professionnel, je l'aurais fait en C++ ou, dans une moindre mesure, dans un langage compilé.

Le but de l'exercice est de concevoir un solveur de A à Z et d'en comprendre le fonctionnement. Pour avoir une application correcte, j'essaye toujours d'explorer toutes les possibilités et de faire au mieux, même pour les détails.

Votre commentaire me fait penser à un article lu sur ce forum. Selon l'auteur, les enseignements JAVA ne sont pas à la hauteur et l'élève fait toujours n'importe quoi quand il doit aller en entreprise. Ça on le sait bien, l'école et le monde professionnel sont très différents. Il conseillait donc aux professeurs d'apprendre aux élèves à utiliser directement les api de java. Et c'est là qu'il rejoint votre commentaire. Je trouve cette attitude dégradante envers l'informatique car c'est avant tout une science à part entière. En mathématique, les élèves doivent démontrer des formules, pourtant c'est déjà fait. En littérature, les élèves doivent écrire des dissertations sur des sujets ressassés des centaines de fois. Et bien en informatique, les élèves doivent concevoir du code qui a déjà été conçu par mille autres avant. Le but de cette manœuvre, aussi pénible puisse-telle vous paraitre, est, je pense, indispensable. Ceci permet d'acquérir les fondements logiques de la programmation. De plus, les choix de conception devant être fait par l'élève lui seront bénéfiques plus tard lorsque dans d'autres projets il sera confronté à des problèmes similaires. Pour finir ce monologue, il me semble qu'on utilise beaucoup mieux des outils dont on comprend les rouages internes (sans ça, il peut souvent arriver qu'on se demande pourquoi un tel choix a été fait. Par exemple, l'invalidation d'un itérateur après une suppression).

Néanmoins, merci pour vos commentaires qui m'ont été utiles. J'espère que vous comprenez mon point de vue.

[dividee]

Je suis d'accord sur le principe que tu défends. Je me suis trompé sur tes objectifs. Je pensais que l'objectif était d'expérimenter avec un solveur SAT.

L'avantage d'un langage comme Python, c'est de pouvoir prototyper rapidement une solution. Pour l'apprentissage, cela permet aussi de se concentrer sur le problème sans devoir trop se préoccuper de certains détails, importants mais non directement liés au problème.

Pour donner un exemple, on peut implémenter l'algorithme de recherche des plus courts chemin de Dijkstra en une dizaine de lignes, grâce à la richesse des structures de données en Python. Pour cela, on utilise, par exemple le type de données set (ensemble). L'implémentation efficace de ce type de données est, en soi, plus complexe que l'implémentation de l'algorithme de Dijkstra qui l'utilise, mais constitue un détail si le but est la recherche des plus courts chemins dans un graphe. De même, la démonstration mathématique de l'algo de Dijkstra n'oblige pas à redémontrer depuis le début la théorie des ensembles...

Ecrire un parser efficace en Python est louable, mais c'est une tâche plus ardue, il me semble, que d'écrire un solveur SAT.

Je ne prône pas la spécialisation de l'enseignement de la programmation sur un petit nombre de librairies utilisées en entreprise, mais je pense tout de même que choisir une librairie adaptée à ses besoins est une compétence qui peut avoir sa place dans un cursus...

[Trademark]

On est bien d'accord dividee

Je ne reviens pas sur ce topic pour ne dire que ça mais pour un problème d'inclusion.

Le dossier du projet est composé entre autre de

Code :

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

1
2
3
4
5
 
+src
  |- librairie.py
+test
  |- fichier_test.py

Le fichier_test ne trouve pas la librairie et malgré que j'ai fait : sys.path.append("../src/librairie.py") sys.path.append("../src") dans fichier_test.py.

Quelle est la solution à mon problème ?

[mont29]

Ce serait pas plutôt sys.path.append("../src")*? Le path contient des dossiers où chercher les fichiers, pas directement des fichiers…

[Trademark]

Je ne sais pas pourquoi j'ai marqué ça dans le message . Dans mon code j'ai bien fait :

Code :

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

sys.path.append("../src")

Mais ça ne marche pas.

[dividee]

La notion de répertoire courant n'est pas très bien adaptée aux environnements fenêtrés modernes... Quand tu lances fichier_test.py, rien ne garantit que le répertoire courant est celui qui contient le fichier.
Il vaut mieux référencer explicitement __file__, comme ceci:

Code :

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

os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'src'))