Version imprimable
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.Citation:
Ben non, que ce soit avec for ou enumerate, tu consommes l’itérateur
Bien vu mont29 :ccool:
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.Citation:
Envoyé par Trademark
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...
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.
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...
On est bien d'accord dividee 8-)
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
Le fichier_test ne trouve pas la librairie et malgré que j'ai fait :Code:
2
3
4
5
sys.path.append("../src/librairie.py")sys.path.append("../src") dans fichier_test.py.
Quelle est la solution à mon problème ?
Ce serait pas plutôt sys.path.append("../src")*? Le path contient des dossiers où chercher les fichiers, pas directement des fichiers…
Je ne sais pas pourquoi j'ai marqué ça dans le message :aie:. Dans mon code j'ai bien fait :
Mais ça ne marche pas.Code:sys.path.append("../src")
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:os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'src'))