Ok, also mein Rat wäre: "Mache" doch auch Softwareentwicklung, wenn das schon im Titel steht. D.h. *nutze* sinnvolle Bibliotheken, die Dich zum Ziel führen. Das Ziel ist es offensichtlich *nicht*, einen Parser für mathematische Terme zu schreiben, sondern einen Funktionsplotter! Insofern verstehe ich Deine Abneigung gegen Sympy nicht - zumal Du ja auch Numpy benutzt...
Im Sinne der Softwareentwicklung muss man sich bei jedem Projekt die Frage stellen, *was* man für sein Projekt braucht, *was* es da ggf. an *fertigen* Modulen gibt und ggf. *welche* man dafür benutzen will. Da können viele kriterien ausschlaggebend sein, etwa die Lizenz, die "Reife" einer Lib, usw.
Natürlich kann man auch zu dem Punkt gelangen, dass man sich entscheidet, etwas selber zu implementieren, aber das ist Abwägungssache. Und Du hast uns bisher nichts genannt, was das rechtfertigen würde
Wenn es Dich persönlich interessiert: Prima, versuche das (nebenbei!) umzusetzen in Deiner Freizeit. Später kannst Du es ggf. in Dein Projekt einbauen. Aber um erst einmal zu einem vernünftigen Ergebnis zu kommen, nutze doch einfach die Lib, die das bereits gelöst hat, was Du suchst.
Wenn ich mir den Code so ansehe, fallen mir da leider auch ganz viele konzeptionelle Fehler auf... ich denke da ist es sinnvoller, an denen zu arbeiten als sich mit einer komplexen (wenn vielleicht auch spaßigeren) Sache wie einem Parser rumzuschlagen.
Beispiel:
- eine Klasse ``app`` zu nennen ist... niemals sinnvoll, es sei denn, ein Rahmenwerk würde dies fordern
- Deine Klasse macht viel zu viel! Du verletzt damit das
SRP Insbesondere das Berechnen der Werte gehört nicht in eine Klasse für die Darstellung!
- im Grunde kannst Du obige Punkte verbessern, indem Du eine klare Trennung von GUI und Logik durchführst. Schreibe also Funktionalität zum Berechnen der zu plottenden Werte, zum Plotten an sich und für die reine GUI.
- Beachte PEP8! Du wechslst auch in Deinem Benennungsstil, was es noch unübersichtlicher macht.
- Benutze Doc-Strings, am besten mit Notation, die
Sphinx versteht.
- Versuche wenigstens einige Dinge mittels Unit-Tests abzudecken! Sich darin einzuarbeiten ist wesentlich sinnvoller, als einen Formel-Parser zu bauen. Speziell das Wandeln einer Formel von der Eingabe zu einer maschinell auswertbaren Struktur sollte man relativ einfach testen können. Das scheint ja ein Kernpunkt bei Deinem Projekt zu sein. Aber auch das Berechnen von Werten an sich und ggf. auch Sonderfälle.
Vermutlich musst Du ja nicht nur den reinen Quellcode "abgeben", sondern auch beschreiben, wieso und wie Du etwas umgesetzt oder weggelassen hast. Da würde ich dann eher auf Funktionalität verzichten und anmerken, dass das in einer späteren Iteration nachgeliefert werden muss, und das damit rechtfertigen, dass der Code wartbar, erweiterbar und idiomatisch sauber ist.