[geklärt] Problem mit reStructuredText @ epydoc

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Sonntag 31. Dezember 2006, 01:35

Hi.

Code: Alles auswählen

::

  Whitespace, newlines, blank lines, and
  all kinds of markup (like *this* or
  \this) is preserved by literal blocks.
Wenn ich das so verwende und dann epidoc benutze wird mir das \ nicht angezeigt. Warum? Ich suche eine Möglichkeiten wie ich mir \, \n anzeigen lassen kann ohne \\, \\n

...

Hab auch ein Problem bei >>>.

Wenn ich z.B.

Code: Alles auswählen

"""
>>> li = ["print 'foobar'", "def \\\n", "foobar\\\n", "():", "    pass"]
"""
gibt es Probleme mit den \\\n.
Line 263: Definition list ends without a blank line: unexpected unident
Stimmt aber nicht die Fehlermeldung :roll:

Was soll der mist?

lg

P.S.: Auf ``def \\\\\\n`` statt ``def \\\n`` habe ich keine Bock, weil man die Doku auch mit `help()` lesen und ohne epidoc output verstehen können sollte...
Zuletzt geändert von sape am Mittwoch 3. Januar 2007, 07:28, insgesamt 2-mal geändert.
BlackJack

Sonntag 31. Dezember 2006, 12:04

sape hat geschrieben:Hi.

Code: Alles auswählen

::

  Whitespace, newlines, blank lines, and
  all kinds of markup (like *this* or
  \this) is preserved by literal blocks.
Wenn ich das so verwende und dann epidoc benutze wird mir das \ nicht angezeigt. Warum?
Weil da in der letzten Zeile '\t' am Anfang steht, also ein Tabulator-Zeichen.
Hab auch ein Problem bei >>>.

Wenn ich z.B.

Code: Alles auswählen

"""
>>> li = ["print 'foobar'", "def \\\n", "foobar\\\n", "():", "    pass"]
"""
gibt es Probleme mit den \\\n.
Jo:

Code: Alles auswählen

In [7]: a = """
   ...: >>> li = ["print 'foobar'", "def \\\n", "foobar\\\n", "():", "    pass"]   ...: """

In [8]: print a

>>> li = ["print 'foobar'", "def \
", "foobar\
", "():", "    pass"]
Line 263: Definition list ends without a blank line: unexpected unident
Stimmt aber nicht die Fehlermeldung :roll:
Vielleicht stimmt sie doch. Ohne den Quelltext um das nachvollziehen zu können, lässt sich das aber schlecht sagen.
P.S.: Auf ``def \\\\\\n`` statt ``def \\\n`` habe ich keine Bock, weil man die Doku auch mit `help()` lesen und ohne epidoc output verstehen können sollte...
Hast Du Deine Doku mal mit `help()` ausprobiert?

Code: Alles auswählen

In [9]: def f():
   ...:     """
   ...:     >>> li = ["print 'foobar'", "def \\\n", "foobar\\\n", "():", "    pass"]
   ...:     """
   ...:     pass
   ...:

In [10]: help(f)

Help on function f in module __main__:

f()
        >>> li = ["print 'foobar'", "def \
    ", "foobar\
    ", "():", "    pass"]
Das ist nicht das was Du willst oder?
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Sonntag 31. Dezember 2006, 13:06

Sollte das nicht \\n statt \\\n sein? Letzteres ist ja gerade ein Backslash gefolgt von einem Newline...
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Dienstag 2. Januar 2007, 11:08

Weil da in der letzten Zeile '\t' am Anfang steht, also ein Tabulator-Zeichen.
Eben nicht. Mir ist schon klar dass so was interpretiert wird. Ich nutze zum Beispiel in Docstrings auch das \ (genauer -> \\n ohne \n) um Zeilen zu verbinden. Aber :: soll ja gerade das escaping verhindern :) Hier das Beispiel: http://docutils.sourceforge.net/docs/us ... ral-blocks
Deshalb wundert mich das der ganze Markup Kram wie *foobar* im Beispiel geht aber eben nicht die escapes. Ich denke das ist in epydoc einfach noch nicht implementiert(?).
Hast Du Deine Doku mal mit `help()` ausprobiert?
Ne hatte ich noch nicht. OK, dann weiß ich das es nicht an epydoc liegt sondern an Python, selber.

...

Ich denke, das Thema scheint vorerst geklärt. Ich habe nun mehrer Varianten mit :: probiert und keine Klappt wie in den Specs zu reSTR. Vielleicht wird es in eine neuere Version von epydoc umgesetzt wird.

lg
BlackJack

Dienstag 2. Januar 2007, 12:29

sape hat geschrieben:
Weil da in der letzten Zeile '\t' am Anfang steht, also ein Tabulator-Zeichen.
Eben nicht. Mir ist schon klar dass so was interpretiert wird. Ich nutze zum Beispiel in Docstrings auch das \ (genauer -> \\n ohne \n) um Zeilen zu verbinden. Aber :: soll ja gerade das escaping verhindern :) Hier das Beispiel: http://docutils.sourceforge.net/docs/us ... ral-blocks
Deshalb wundert mich das der ganze Markup Kram wie *foobar* im Beispiel geht aber eben nicht die escapes. Ich denke das ist in epydoc einfach noch nicht implementiert(?).
Doch da steht ein Tabulatorzeichen. Das ist eine Python Zeichenkette und keine Textdatei. Wenn Du mit den Beispielen aus der reST-Doku vergleichst, dann musst Du schon die Zeichenketten so schreiben, dass sie mit ``print`` ausgegeben so aussehen wie die Beispiele und nicht im Python-Quelltext.
Ich denke, das Thema scheint vorerst geklärt. Ich habe nun mehrer Varianten mit :: probiert und keine Klappt wie in den Specs zu reSTR. Vielleicht wird es in eine neuere Version von epydoc umgesetzt wird.
Nochmal: Als allererstes musst Du die Regeln berücksichtigen die von literalen Zeichenketten in Python vorgegeben sind.

Code: Alles auswählen

"""
::
  \this
"""
Irgendwie scheinst Du zu erwarten, dass hier das '::' verhindert das '\t' zu einem Tabulatorzeichen wird. '::' hat in Zeichenketten in Python aber absolut keine besondere Bedeutung. Wenn Du dort einen Backslash und ein 't' stehen haben willst, dann musst Du den Backslash schützen.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Dienstag 2. Januar 2007, 13:20

BlackJack hat geschrieben:[...]Irgendwie scheinst Du zu erwarten, dass hier das '::' verhindert das '\t' zu einem Tabulatorzeichen wird.
[...]
So hatte ich das Beispiel im Link verstanden :?
BlackJack hat geschrieben:[...]
'::' hat in Zeichenketten in Python aber absolut keine besondere Bedeutung. Wenn Du dort einen Backslash und ein 't' stehen haben willst, dann musst Du den Backslash schützen.
Aber in reSTR leitet das, gefolgt von einer Leerzeile, einen literalen Block ein der doch alle Markups und escapes ausschalten soll. Daher dachte ich das es pydoc schon erkenne würde und das dem entsprechend umsetzt. Aber langsam geht mir da ein Licht auf. Ich glaube Epydoc kann dafür nichts direkt, sondern Python wandelt/Interpretiert die escapes schon beim Parsen, so das Epydoc das nie zu Gesicht bekommt.
BlackJack

Dienstag 2. Januar 2007, 16:12

sape hat geschrieben:Aber langsam geht mir da ein Licht auf. Ich glaube Epydoc kann dafür nichts direkt, sondern Python wandelt/Interpretiert die escapes schon beim Parsen, so das Epydoc das nie zu Gesicht bekommt.
Bingo.

Und selbst wenn Epydoc den Quelltext selbst parsen würde, müsste es vorher die Regeln für Escapes in Python-Zeichenketten anwenden, weil die Epydoc-generierte Doku sonst mit der `help()`-Funktion und Doctests inkompatibel wäre.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Mittwoch 3. Januar 2007, 07:29

OK, dann hatte ich das falsch verstanden.

Danke & lg
sape
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Mittwoch 3. Januar 2007, 09:10

Ich werfe noch raw strings ein.
TUFKAB – the user formerly known as blackbird
Antworten