Wildcard-Problem unter Windows

[kyou]

Ergänzung zu meinem vorherigen Beitrag:

Bringt dir das was für dein Vorhaben? In dem Fall könnte ich natürlich noch die Behandlung von Carets mit aufnehmen...

Das kann ich nicht einschätzen, weil ich schlichtweg kein Python kann. Im Grunde ist Subst ja nicht mein Vorhaben, sondern ein Projekt des Entwicklers von Subst. Ich will das Programm natürlich nutzen. Deswegen sollte es bugfrei sein. Aber welche Features in das Programm eingebaut werden sollen, ist nicht meine Entscheidung. Mein Engagement auf Github beschränkt sich bezüglich Subst darauf, Bugs zu melden und dem Entwickler im Rahmen meiner Möglichkeiten zu helfen, sie zu beseitigen, also z. B. möglichst schnell zu reagieren, wenn er eine Änderung an Subst vorgenommen hat und ihm zu schreiben, ob sie unter Windows funktioniert. Dabei versuche ich, ihm nicht Probleme mit Subst zu melden, die nur deshalb entstehen, weil ich z. B. nicht verstanden habe, wie reguläre Ausdrücke funktionieren. Ich überlege also dreimal, bevor ich dem Entwickler ein neues Problem melde, weil ich ihm nicht die Zeit stehlen will. Die Zeit, die er sich für Erklärungen nimmt, ist Zeit, die nicht mehr für die Beseitigung von Bugs zur Verfügung steht.

In Bezug auf mein Vorhaben, Subst für die Ersetzungen in dekompilierten Fonts einzusetzen: Ich kann es bereits jetzt nutzen. Noch brauche ich das Caret nicht in meinen Mustern. Und Wildcards brauche ich derzeit auch nicht in den Befehlen von Subst, weil ich die Befehle innerhalb einer For-Schleife meines Batch-Scripts abarbeiten lasse. Aber ich wünsche mir halt eine Ersetzungssoftware, die bugfrei ist, um nicht später in Probleme zu rennen, wenn ich mir bereits sehr viel Arbeit mit der Erstellung der Muster gemacht habe.

Anscheinend bist du nicht daran interessiert, dass statt Anpassungen als Alternative einfach neuer Code geschrieben wird.

Da hätte ich gar nichts gegen. Nur kann ich eben kein Python. Deswegen hatte ich ursprünglich auch nicht die Absicht, die Bugs hier in diesem Thread zu diskutieren. Ich bin schlichtweg nicht kompetent genug, um in Bezug auf den Code mehr zur Beseitigung der Bugs beizutragen, als ich bisher beigetragen habe. Es ging vielmehr darum, auf Subst aufmerksam zu machen, und zwar in der Hoffnung, dass Python-Programmierer, die das Skript ebenfalls für nützlich halten, in das Projekt einsteigen. Außer mir gab es nur eine andere Person, die dem Entwickler ein Problem gemeldet hat. Und ich vermute, das liegt entweder daran, dass fast niemand Subst kennt oder dass die meisten keine Notwendigkeit darin sehen, ein Skript wie Subst zu programmieren, weil es für sie bessere Alternativen gibt.

[kyou]

Der Bug mit dem Caret ist jetzt anscheinend gefixt. Und Wildcards funktionieren jetzt halbwegs. Allerdings lässt Subst noch Ordner als Dateien durchgehen, was in einer Fehlermeldung endet.

[snafu]

Ein wenig Inspiration hat mein Code wohl schon gebracht, wenn ich seine Antworten so lese. Wie gesagt, bei mir war's in einem Projekt mit anderer Thematik. Da hat sich diese "magische" Unterscheidung zwischen Auflösung der Namen vs Anzeige der Verzeichnisinhalte richtig angefühlt. Habe hierfür aber auch kein Feedback erhalten, sodass ich nicht wirklich einschätzen kann, ob mein Vorgehen hilfreich für andere User ist...

Allerdings lässt Subst noch Ordner als Dateien durchgehen, was in einer Fehlermeldung endet.

Das kann man nur anhand des Namens leider nicht erkennen. Möglicherweise schafft der Einbau von os.path.isdir(filename) (dann mit angepasstem Verhalten) hier Abhilfe.

[bwbg]

Ich habe den Projekt-Code auch nur überflogen. Ich schließe mich an, dass dieser komplizierter ist, als er sein müsste. So habe ich mich dem Kernproblem, dem Ersetzen von Text gewidmet und folgende Funktion (mit type-hints) zusammengeschraubt:

Code: Alles auswählen

def subst(pattern:str, replacement:Union[str, None]=None) -> Callable[[str], str]:
    """Returns a function which substitues and replaces a given string
    according to the given pattern and replacement-rule. """
    def func(string:str) -> str:
        match = re.compile(pattern).match(string)
        return (replacement.format(*match.groups())
                if (match and replacement)
                else (string if match else None))
    return func

Das ganze kann man wie folgt anwenden:[codebox=pycon file=Unbenannt.txt]>>> s = subst('^do#(\\d+)#([xyz])$', '{1} = {0}')
>>> s('do#34#x')
'x = 34'
>>> s('do#34#z')
'z = 34'
>>> s('do#34#q')
>>> type(s('do#34#q'))
<class 'NoneType'>
[/code]

Die Ausrede "ich kann kein Python" solltest du in eine Aussage "ich kann noch kein Python" ändern. Aus den Beispielen hier konnte ich eine Menge lernen.

Die Kenntnisse, welche Du Dir hier aneignen solltest sind:

1. Funktionen und Funktionen "höherer Ordnung"
2. tuple-unpacking
3. conditional-expression (if-else-Ausdruck)

[kyou]

Ein wenig Inspiration hat mein Code wohl schon gebracht, wenn ich seine Antworten so lese.

Warum auch nicht? Der Entwickler scheint ein sehr netter und für Vorschläge empfänglicher Mensch zu sein. Es hat nur keinen Sinn, dass ich als eine Art Vermittler und Übersetzer zwischen euch und dem Entwickler des Skripts auftrete. (Github ist ja für Gemeinschaftsprojekte ausgelegt.) Dafür spreche ich weder gut genug Englisch, noch sind meine Python-Kenntnisse dafür ausreichend. Das geht meiner Ansicht nach aber schon aus meinem Erstbeitrag hervor. Ich bat nicht darum, mir zu helfen, das Skript zu verbessern, sondern euch zu entscheiden, ob ihr selbst eine Verwendung dafür habt. Und falls ja, ob ihr euch bei dem Projekt auf Github engagieren wollt oder nicht. Und wenn ihr merkt, dass das Skript zwar prinzipiell nützlich ist, aber der Code so kompliziert, dass es sich nicht lohnt, ihn zu verbessern, sondern ein Skript mit einer vergleichbaren Funktionalität von Grund auf neu zu programmieren, dann würde ich mich freuen, wenn ihr das im Rahmen eigener Github-Projekte tätet. Das Bessere ist ja des Guten Feind. Insofern habe ich gewiss nichts gegen Alternativen, ganz im Gegenteil.