[Gelöst] Ist parsen eine regex Aufgabe?

[TRex]

Das sind raw-Strings, und mit regex haben die nichts zu tun - sie sind dafür aber praktisch. Normalerweise müsstest du alle backslashes escapen (also sie zweimal schreiben), und mit raw string (korrekterweise raw string literals) musst du das nicht.

Siehe auch: https://docs.python.org/3/reference/lex ... ml#strings

Both string and bytes literals may optionally be prefixed with a letter 'r' or 'R'; such strings are called raw strings and treat backslashes as literal characters.

[buhtz]

Das sind raw-Strings, und mit regex haben die nichts zu tun - sie sind dafür aber praktisch. Normalerweise müsstest du alle backslashes escapen (also sie zweimal schreiben), und mit raw string (korrekterweise raw string literals) musst du das nicht.

Das regex Modul in Python scheint das aber nicht zu stören. Bzw. sind die Backslashes ja keine Zeichen, sondern bereits Escape-Einleitungen. Also wenn ich tatsächlich, so wie die Linter das wollen, diese nochmal escapen würde, würde vermutlich regex nicht mehr gehen.

[TRex]

Sorry, war auch ein wenig unvollständig/falsch - escapen musst du einzelne \ nicht, aber würdest du \n (oder \t, \r, ...) im regex verwenden wollen, gehts vermutlich schief ohne wahlweise \\n oder eben r"\n". Habs nicht ausprobiert, aber so interpretiere ich die Doku.

[Meillo]

Bedeutet das, dass in Python r'...' und r"..." das Aequivalent zu Single Quotes in der Shell sind?

Normale '...' und "..." sind dann wohl austauschbar und entsprechen den Double Quotes in der Shell, vermute ich.

[eggy]

Bedeutet das, dass in Python r'...' und r"..." das Aequivalent zu Single Quotes in der Shell sind?

Normale '...' und "..." sind dann wohl austauschbar und entsprechen den Double Quotes in der Shell, vermute ich.

Und """...""" gibts auch noch.

https://peps.python.org/pep-0008/#naming-conventions
pep8 unter String Quotes sagt:

In Python, single-quoted strings and double-quoted strings are the same. This PEP does not make a recommendation for this. Pick a rule and stick to it. When a string contains single or double quote characters, however, use the other one to avoid backslashes in the string. It improves readability.

For triple-quoted strings, always use double quote characters to be consistent with the docstring convention in PEP 257.

und das sagt, neben anderem:

For consistency, always use """triple double quotes""" around docstrings. Use r"""raw triple double quotes""" if you use any backslashes in your docstrings. For Unicode docstrings, use u"""Unicode triple-quoted strings""".

There are two forms of docstrings: one-liners and multi-line docstrings.

(ka, obs da noch nen aktuelleres pep gibt, dass man kennen sollte, bin da grad nicht so auf dem Laufenden)

[buhtz]

Ich hab noch ein AddOn. Das Pattern funktioniert nicht wenn ein Linebreak im String ist.
Soweit ich verstehe arbeitet Regex per default nur Zeilenweise. Das lässt sich aber scheinbar ändern. Hierzu finde ich \X, \s und den Punkt. Habe es auf regex101 aber bisher nicht hinbekommen.

Das hier wäre zu parsen.

Code: Alles auswählen

[[id:0c664422c239][foo bar with linebreak
in second line]]

Für mich ist OK, wenn im Ergebnis dass dann so aussieht:

Code: Alles auswählen

['0c664422c239', 'foo bar with linebreak\nin second line']

Die ID, also das zweite Feld, dürfte in meiner Situation nie Linebreaks beinhalten.

Das hier ist das ursprüngliche Pattern: \[\[id:(.+?)\]\[(.+?)\]\]

[buhtz]

Das hier ist das ursprüngliche Pattern: \[\[id:(.+?)\]\[(.+?)\]\]

Jetzt hab ich's wie ich das X reinbasteln muss.

Code: Alles auswählen

\[\[id:(.+?)\]\[(.\X+?)\]\]

Funktioniert. Macht das für die erfahrenen Regexer auch Sinn?

[Meillo]

Soweit ich verstehe arbeitet Regex per default nur Zeilenweise. Das lässt sich aber scheinbar ändern.

Das ist korrekt. Ich kenne mich mit Python nicht aus, aber `re.MULTILINE|re.DOTALL' als drittes Argument von `findall()' koennte die Loesung sein.

[buhtz]

Zum Thread: Interessensabfrage: Wer will RegExps lernen?

[buhtz]

Mhm... Ich denke ich bleibe jetzt mal in diesem Thread, da sich das Thema nicht wirklich geändert, sondern nur der Schwierigkeitsgrad erhöht hat.

Im Kontext von Org-Mode gibt es Links mit und ohne Label, die in dieser Form in HTML übersetzt werden.

Code: Alles auswählen

[[https://foo.bar]]
<a href="https://foo.bar">https://foo.bar</a>

[[https://foo.bar][foobar]]
<a href="https://foo.bar">foobar</a>

Ich habe für beide je auch ein RegEx (hier als Python r-String dargestellt)

• r'\[\[(?!id\:)(.+?)\]\[(.+?)\]\]'
• r'\[\[(?!id\:)(.+?)\]\]'

In beiden RegEx wird darauf geachtet, dass "Sonderfall"-Links die mit "[[id:" beginnen, ignoriert werden.

Jetzt der Knüller. Beide Link-Varianten kommen in einem String vor.

Code: Alles auswählen

[[https://foo.bar]] and [[https://foo.bar][foobar]]

Das erste RegEx führt im Ergebnis zu diesen beiden Gruppen

Code: Alles auswählen

https://foo.bar]] and [[https://foo.bar
foobar

Warum das passiert, kann ich einigermaßen nachvollziehen. Eine Lösung, auch einfach nur konzeptionell unabhängig von RegEx, will mir aber nicht einfallen.

Die Reihenfolge der RegEx-Varianten umzukehren hilft nicht, weil auch die Link-Varianten anders herum auftauchen können.

Also die Frage ist eigentlich, was ich hier überhaut will:
Vermutlich benötige ich zwei RegEx Pattern, eines für jede Link-Variante. Diese Pattern müssen aber die andere Link-Variante ignorieren/übersehen können.

EDIT: Beim ersten RegEx darf in Gruppe 1 kein "]]" vorkommen. Das sind also verbotene Zeichen.

[buhtz]

Die Credits gehen an Wiktor Stribiżew und seine Antwort auf meine SO Frage.

Nebenbei habe ich die Pattern jetzt auch so abgeändert, dass Sie nicht mehr ID-Links ausschließen, sondern einfach "andersherum" explizit/positiv exklusiv nach HTTPS-Links suchen.

Hier werden Org-HTTPS-Links mit Label gesucht

Code: Alles auswählen

\[\[https\:\/\/([^\]\[]+)\]\[(.+?)\]\]

Hier werden Org-HTTPS-Links ohne Label gesucht

Code: Alles auswählen

\[\[https\:\/\/([^\]\[]+)\]\]

Meinen Unittests nach kommen sich diese auch nicht ins Gehege, wenn ich alle Link-Typen in einem String kombiniere.

EDIT: Interessant daran ist, dass ich Herr Stribiżew Erklärung sofort verstehe, auch die Alternativen Lösungsmöglichkeiten. Aber 1 Minute später kann ich das schon nicht mehr nachvollziehen, wenn ich mir das Pattern anschaue. RegEx will mir einfach nicht in der Birne hängen bleiben.