Ipython: Verweise auf Python-Variablen in Markdown-Zellen zulassen

Erstellt am 20. Feb. 2013  ·  49Kommentare  ·  Quelle: ipython/ipython

In PR #2592 hat @Carreau eine Syntax entwickelt, um auf Python-Variablen in Markdown-Zellen zu verweisen. Es verwendet die {{x}} Syntax im Jinja-Stil. Wir lieben diese Idee, aber es gibt einige Dinge, die erarbeitet werden müssen:

  • [ ] Welche Syntax verwenden wir? Sind wir zufrieden mit dem {{}}
  • [ ] Wie stellen wir sicher, dass wir Markdown auf robuste und vernünftige Weise für Latex und Literaten verarbeiten. Wir weichen langsam vom reinen Markdown ab und das ist wirklich gefährlich. Wir möchten, dass das Notebook-Format sehr breit gefächert ist, und eine eigene Markdown-Syntax scheint eine schlechte Idee zu sein.
  • [ ] Umgang mit Fehlern, dh undefinierten Variablen.
  • [ ] Was wollen wir mit anderen Anzeigeformaten machen. Scheint ein gefährlicher Weg zu sein, um Nicht-Text-Formate zuzulassen.
closed-pr notebook

Hilfreichster Kommentar

Ich denke, diese Funktion ist wirklich wichtig für jemanden, der von Rmarkdown kommt. R hat beim Erstellen schöner Berichte viel bessere Arbeit geleistet.

Alle 49 Kommentare

Also, ist das tot? Es wäre toll, wie der vorherige Thread darauf hingewiesen hat? Es tut mir leid, dass ich wünschte, ich hätte die Fähigkeit, dies zu implementieren (ich nicht), aber ich würde es auf jeden Fall verwenden ...

Nicht tot, muss nur ein paar Dinge zuerst erledigen.

Ich habe gerade auf SO danach gefragt, nur um festzustellen, dass es ein doppeltes Duplikat von hier und hier war .

Meine 2c wäre das

  • Jinja-Syntax wäre toll
  • Auf den ersten Blick scheint Markdown nicht wirklich "rein" zu sein , aber wenn alle Formatierungskonventionen einer etablierten Implementierung (:octocat: github wäre eine nette) befolgt würden, dann ist das Hinzufügen einer Injektionsmethode nicht möglich eigentlich ein Abschlagsproblem.
  • Könnten Fehler eine vom Benutzer konfigurierbare Sache sein? Eine Option von [unsichtbar (nichts passiert), das Wort error oder ein schmutziger großartiger Stack-Trace ]
  • Solange es sich um eine Textantwort handelt, könnte sie eingefügt werden, bevor sie an den Markdown-Renderer übergeben wird, also könnte sie HTML oder noch mehr Markdown einfügen!

Ich möchte keine bestimmte Syntax befürworten (ich denke, {{}} ist in Ordnung), aber hier ist ein vergleichbares Design für R: http://www.rstudio.com/ide/docs/authoring/using_markdown (Sie verwenden ``` als Trennzeichen ).

Lunamark verwendet

:+1:

:+1:, das wäre eine sehr nützliche Funktion!

Es wäre wirklich schön, die gleiche Syntax wie http://blog.rstudio.org/2014/06/18/r-markdown-v2/ zu haben.

Ich weiß nicht, mit den Trennzeichen im R-Stil, dh einzelnen bzw. dreifachen Backticks, scheint es, als könnten wir nicht wählen, ob wir nur Code anzeigen (wie some code snippet/example ) und Code _evaluieren_ und das Ergebnis anzeigen ( zB my_var ) - Ich glaube nicht, dass das sehr praktisch ist (wenn ich es richtig verstehe).

Der Anwendungsfall ist das Schreiben von Notebook-Prosa mit eingebetteten berechneten Werten, wie zum Beispiel "_Die durchschnittliche Arbeitslosigkeit für Morgan County im Jahr 2014 betrug 8,4 %, gegenüber 10,3 % im Jahr 2009._" In diesem Beispiel können Sie sich vorstellen, dass die Prozentsätze und Jahre berechnet werden aus Daten.

Der breitere Anwendungsfall sind "intelligente Dokumente", bei denen Sie Text und Grafiken automatisch (neu) aus den Daten generieren lassen (möglicherweise den Code aus Gründen der Lesbarkeit verstecken).

Ich denke, es ist eine nützliche Funktion.

Das "knitr"-Modell in rstudio gefällt mir sehr gut (ein Markdown-Dokument, Codeblöcke werden interpretiert, Werte sind im Markdown verfügbar -> wird in PDF/html/ umgewandelt... welches ich als Zeitschriftenartikel veröffentlichen kann. Anders als ein Notebook da das Notebook auf mehreren Zellen basiert und ich nicht sicher bin, wie ich beeinflussen kann, ob die Ausgabe angezeigt wird oder nicht).

Es macht mir nichts aus, wie die Werte in den Text aufgenommen werden, aber ich fände es schön, wenn sowohl R (mit knitr/rstudio) als auch ipython dasselbe verwenden würden.

Oder etwas Ähnliches wie ruby ​​oder bash, wobei #{varname or statement} sein kann
innerhalb der Saite gemischt.

  1. Juni 2014 20:27 skrev "Jan Schulz" [email protected] følgende:

Ich mag das "knitr" -Modell in rstudio sehr (ein Markdown-Dokument, Code
Blöcke werden interpretiert, Werte sind im Markdown verfügbar -> werden konvertiert
in PDF/html/..., das ich als Zeitschriftenartikel veröffentlichen kann. Anders als a
Notebook, da das Notebook auf mehreren Zellen basiert und ich nicht sicher bin, wie das geht
Einfluss darauf, ob die Ausgabe angezeigt wird oder nicht).

Es macht mir nichts aus, wie die Werte in den Text aufgenommen werden, aber ich würde es finden
schön, wenn sowohl R (mit knitr/rstudio) als auch ipython dasselbe verwenden würden.


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/ipython/ipython/issues/2958#issuecomment -46875435.

Ich kenne den Anwendungsfall von interpretiertem Code natürlich, ich mache mir nur Sorgen, dass wir die Fähigkeit von Markdown verlieren würden, Code "nur" anzuzeigen (ohne ihn zu interpretieren/auszuwerten), like this , wenn die R-Syntax (dh Backticks) ) wurden ausgewählt.

Ich denke, im knitr/R-Markdown kann man angeben, ob man Code anzeigen möchte (richtig hervorgehoben usw.) oder nur die Ausgabe (Plots, Tabellen,...).

Ich komme aus einem wirtschaftlichen Hintergrund und möchte keinen Code in meinen Papieren sehen, daher unterscheidet sich dies etwas von dem (meiner Meinung nach) optimierten Anwendungsfall des Vorführens von Code.

@bilderbuchi oh Entschuldigung, ich habe den Kontext Ihres Kommentars "glaube nicht, dass das nützlich ist" falsch interpretiert.

Und ich stimme zu: Was auch immer implementiert wird, sollte den bestehenden Abschlag nicht brechen.

Das wäre wunderbar und würde IPython dazu bringen, Stricker zu essen.

https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown

Ich mag diesen Ansatz wirklich: Es wird eine Zelle benötigt und bis zu einem gültigen Markdown vorverarbeitet, sodass keine Änderungen am Markdown-Prozessor erforderlich sind.

sehr schön...wird bald verwendet

Am So, 17. August 2014 um 14:18 Uhr, Jan Schulz [email protected]
schrieb:

https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/ipython/ipython/issues/2958#issuecomment -52431760.

Tom Brander
http://tombrander.com -Immobilien
http://oswco.com - Offene Software
3763 West Jackson Boulevard.
Birmingham, AL 35213
Telefon 205-267-1089
@dartdog

:+1: elegant. werde ich auch verwenden.

@JanSchulz , danke! Ich freue mich wirklich darauf, Python-Markdown auszuprobieren.

Gibt es eine Chance, dies in das Haupt-IPython ( jupyter ) zu bekommen?

Gibt es eine Chance, dies in Main Ipython (Jupyter) zu bekommen?

Wahrscheinlich nicht bald. Damit das funktioniert, müssen wir viel im Hintergrund designen.
Vor allem bräuchten wir eine offizielle Möglichkeit, die Markdown-Syntax zu erweitern, anstatt nur eine neue zu erfinden.

Tatsächlich funktioniert dies (und auch knitr/rmarkdown AFAIK) durch eine zweistufige Konvertierung: zuerst das Ersetzen von Codeblöcken durch die Ausgabe des Codes und dann die Konvertierung des Rests als Standard-Markdown. Dies ist also keine Erweiterung von Markdown, sondern ein Präprozessor für eine Zelle.

Ich denke, die schwierige Frage ist, wie man willkürlichen unsichtbaren Python-Code handhabt, der innerhalb einer Markdown-Zelle ausgeführt wird. Ich glaube nicht, dass die Ausführung von Code in einer nützlichen Implementierung eingeschränkt werden kann.

Solange es sich um eine separate Erweiterung handelt, die Sie aktiv installieren und aktivieren müssen, ist dies eine andere Sache. Außerdem wird Python-Code nur ausgeführt, wenn dem Notebook vertraut wird.

Ich plane, einen Tooltip hinzuzufügen, der den Quellcode anzeigt, wenn Sie mit der Maus über die Ausgabe des Python-Codes in einer Markdown-Zelle fahren, damit Sie sehen können, woher dieser stammt.

Tatsächlich funktioniert dies (und auch knitr/rmarkdown AFAIK) durch eine zweistufige Konvertierung: zuerst das Ersetzen von Codeblöcken durch die Ausgabe des Codes und dann die Konvertierung des Rests als Standard-Markdown. Dies ist also keine Erweiterung von Markdown, sondern ein Präprozessor für eine Zelle.

Das ist ein benutzerdefinierter Abschlag. Das haben wir mit Mathjax schon. Die müssen wir natürlich lagern
Un-Preprocessing-Markdown für den Fall, dass Sie das Notebook erneut ausführen, also muss jedes Tool, das unseren Markdown verwenden möchte, mit der benutzerdefinierten Vorverarbeitung umgehen.
Pre- oder Postprozessor, wir erfinden unsere eigene Syntax, die mit dem, was die Leute tun wollen oder später tun, in Konflikt stehen kann oder auch nicht.

Ich denke, die schwierige Frage ist, wie man willkürlichen unsichtbaren Python-Code handhabt, der innerhalb einer Markdown-Zelle ausgeführt wird. Ich glaube nicht, dass die Ausführung von Code in einer nützlichen Implementierung eingeschränkt werden kann.

Solange es sich um eine separate Erweiterung handelt, die Sie aktiv installieren und aktivieren müssen, ist dies eine andere Sache. Außerdem wird Python-Code nur ausgeführt, wenn dem Notebook vertraut wird.

Ich plane, einen Tooltip hinzuzufügen, der den Quellcode anzeigt, wenn Sie mit der Maus über die Ausgabe des Python-Codes in einer Markdown-Zelle fahren, damit Sie sehen können, woher dieser stammt.

Wenn wir das tun, könnten wir uns auf user_variable beschränken, dh den Wert des user_ns Schlüssels zurückgeben. Das sollte die meisten Hinrichtungen verhindern.

Wenn wir das tun, könnten wir uns auf user_variable beschränken, dh den Wert des user_ns-Schlüssels zurückgeben. Das sollte die meisten Hinrichtungen verhindern.

Sie möchten auch Aufruffunktionen zulassen. Ein trivialer Fall wäre das Formatieren der Ausgabe oder das Aufrufen eines benutzerdefinierten _repr_.

Ich würde mich freuen, wenn so etwas umgesetzt würde. Es sieht so aus, als ob die einfachste Lösung darin besteht, MD-Zellen durch einen Jinja-Filter zu leiten. Dies wurde schon einmal gemacht. Siehe zum Beispiel dexi .

Auf der anderen Seite denke ich nicht, dass dies standardmäßig in allen Zellen aktiviert sein sollte. Jinja würde die Komplexität des Markups erheblich erhöhen und Jinja+Markdown sollte wahrscheinlich einen anderen Hervorhebungsmodus verwenden als normales MD. Warum implementieren Sie dies nicht als separaten Zelltyp?

Ich denke, dieses Problem könnte verschwinden, wenn es möglich wäre, die Codezelle im Code auszublenden / zu ersetzen, ähnlich wie es derzeit für Markdown getan wird:

-> Fügen Sie eine %%pymarkdown Magie hinzu, die eine text/markdown Meldung ausgibt und angibt, dass die Quelle unsichtbar/durch die Ausgabe ersetzt werden soll. Die Magie würde dann einfach ein s&r innerhalb der Eingabe machen.

[Edit: Ok, es hat andere Probleme, wie keine Syntaxhervorhebung und macht keinen Sinn in der qtconsole...]

Relevant: Mathematica 10 hat Unterstützung für "Berichte" hinzugefügt, siehe: http://www.wolfram.com/mathematica/new-in-10/automated-report-generation/

Ich habe (noch) nicht im Detail damit gespielt, aber es sieht so aus, als ob Sie Notebook als Vorlage verwenden können, um Verweise auf Variablen und berechnete Ausgaben in den Notebook-Text einzubetten.

Angenommen, wir haben mehrere Referenzen in mehreren MD-Zellen auf dieselbe Variable. Welche Zellen sollen bei einer Wertänderung erneut gerendert werden?

@Pipeliner Ich bin mir nicht sicher, worauf Sie hinaus wollen. In iPython/Jupyter-Notebooks muss jede Zelle explizit gerendert werden (entweder durch Strg-Return innerhalb der Zelle oder über Zelle->Alles ausführen in der Menüleiste). Mir ist keine automatische Erkennung veralteter Daten bekannt. Denkst du an knitr/rmarkdown? knitr/rmarkdown versucht, einen Cache mit Ergebnissen aus jeder Zelle zu verwalten und markiert sie als schmutzig, wenn sich die früheren Zellen ändern.

Gibt es Workarounds für dieses Problem, das die Leute verwenden?. Ich liebe Ipython/Jupyter-Notebooks, aber es wäre toll, wenn wir einfach {{ Python Variable }} im Markdown machen könnten. Es ist so praktisch, wenn Sie ein Notebook mit kleinen Beispieldatensätzen vorbereiten und später im vollständigen Satz eintauschen und alles aktualisieren möchten

Sie können ein PlaceProxy-Widget verwenden, um ein Widget an einem beliebigen HTML-Selektor auf der Seite zu rendern. Betten Sie in Ihrem Markdown ein <span id="myid">placeholder</span> und verwenden Sie später in Ihrem Code etwas wie x=HTML('widget value'), PlaceProxy(child=x, selector='#myid') . Jedes Mal, wenn Sie x.value='something' festlegen, wird die Aktualisierung im Widget angezeigt, das im Markdown angezeigt wird. Siehe https://github.com/ipython/ipywidgets/blob/1e407cef864363c66a23781b8d560a6ac18b3370/ipywidgets/widgets/widget_box.py#L70 für die Definition von PlaceProxy.

Viele Vorbehalte natürlich. Wenn Sie den Markdown bearbeiten, verschwindet das Widget. Wenn Sie das Notizbuch öffnen, wurde das Widget möglicherweise nicht erstellt, sodass es nicht angezeigt wird usw. Sie können jedoch eine Ausgabe innerhalb einer Markdown-Zelle programmgesteuert steuern.

Eine andere Möglichkeit besteht darin, die Zeichenfolge zu erstellen und den Markdown als Ausgabe anzuzeigen, nicht als Markdown-Zelle. Es wird nicht dynamisch aktualisiert, aber jedes Mal, wenn Sie die Zelle auswerten, wird der Markdown aktualisiert.

Sie könnten diese Notebook-Erweiterungen ausprobieren:
https://github.com/ipython-contrib/IPython-notebook-extensions/wiki/python-markdown_v3

Ich wollte den String nicht konstruieren und put ist als Ausgabe, da es mit großen HTML-Strings einfach so chaotisch wird - eine nette Idee, aber daran habe ich nicht einmal gedacht. Aber es gibt definitiv ein paar gute Lösungen, die den Trick machen - danke!

Ich denke, diese Funktion ist wirklich wichtig für jemanden, der von Rmarkdown kommt. R hat beim Erstellen schöner Berichte viel bessere Arbeit geleistet.

Ich habe ein Duplikat dieses Problems im Notebook gesehen. Dies ist bereits mit IPython.display.Markdown in einer Codezelle möglich:

image

from IPython.display import Markdown

one = 1
two = 2
three = one + two

Markdown("# Title")
Markdown("""
# Math
## Addition
Here is a simple addition example: {one} + {two} = {three}
""".format(one=one, two=two, three=three))

Schön! Es wäre auch einfach, ein Dienstprogramm (oder sogar eine %%markdown-Magie) zu schreiben.
die automatisch Variablen aus dem Kernel-Namespace ziehen, damit Sie
tun:

%%markdown

## Subsection

Here is {one} and {two}

Am Mittwoch, 26. April 2017 um 18:35 Uhr, Grant Nestor [email protected]
schrieb:

Ich habe ein Duplikat dieses Problems im Notebook gesehen. Das ist schon möglich
Verwenden von IPython.display.Markdown in einer Codezelle:

[Bild: Bild]
https://cloud.githubusercontent.com/assets/512354/25464012/f434c52c-2aae-11e7-9171-541fb0f6601e.png

von IPython.display Markdown importieren

eins = 1
zwei = 2
drei = eins + zwei

Markdown("#Titel")
Markdown("""# Math## AdditionHier ist ein einfaches Additionsbeispiel: {one} + {two} = {three}""".format(one=one, two=two, three=three))


Sie erhalten dies, weil Sie zugewiesen wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ipython/ipython/issues/2958#issuecomment-297586914 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AABr0CIHhxwNwQF6MiHHy2M612zRnf5Wks5rz_D4gaJpZM4AchzX
.

--
Brian E. Granger
Assoziierter Professor für Physik und Datenwissenschaft
Cal Poly State University, San Luis Obispo
@ellisonbg auf Twitter und GitHub
[email protected] und [email protected]

@ellisonbg Das wäre schön und ich denke, dies ist der richtige Weg (Rendern von Markdown von Python vs. Erweitern von markierten und anderen Markdown-Maschinen auf eine Weise, die möglicherweise nicht erweitert werden sollte). @Carreau Interesse an so etwas?

In Kombination mit der neuen Zellen-Tags-Funktion in notebook (siehe den Beitrag zum Release von notebook 5.0 ) sollten Sie außerdem in der Lage sein, Eingabezellen auszublenden, wenn Sie ein Notebook mit nbconvert konvertieren (zB mit dem nbconvert-hide Tag). @takluyver Funktioniert das Tag nbconvert-hide derzeit mit nbconvert?

Ich glaube nicht, dass dies noch der Fall ist, aber ich denke, wir sollten einige nbconvert-Tags hinzufügen.

+1 für all das! Außerdem arbeiten wir derzeit daran, Ein-/Ausgänge in auszublenden
JupyterLab und kann diesen Zustand für nbconvert beibehalten
Metadaten.

Am Donnerstag, 27. April 2017 um 7:33 Uhr, Grant Nestor [email protected]
schrieb:

@ellisonbg https://github.com/ellisonbg Das wäre schön und finde ich
Dies ist der richtige Weg (Rendern von Markdown von Python vs.
Erweitern von markierten und anderen Abschlagsmaschinen in einer Weise, die es vielleicht
sollte nicht verlängert werden). @Carreau https://github.com/Carreau Any
Interesse an so etwas?

Kombinieren Sie dies zusätzlich mit der neuen Zellen-Tags-Funktion in Notebook
(Siehe den Beitrag zum Release von Notebook 5.0
http://blog.jupyter.org/2017/04/04/jupyter-notebook-5-0/ ), sollten Sie
in der Lage sein, Eingabezellen beim Konvertieren eines Notebooks mit nbconvert auszublenden
(zB mit nbconvert-hide-Tag). @takluyver https://github.com/takluyver
Funktioniert das nbconvert-hide-Tag derzeit mit nbconvert?


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ipython/ipython/issues/2958#issuecomment-297731409 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AABr0BNgLTtlzwbrIjqBquzsE9lhLXchks5r0KdAgaJpZM4AchzX
.

--
Brian E. Granger
Assoziierter Professor für Physik und Datenwissenschaft
Cal Poly State University, San Luis Obispo
@ellisonbg auf Twitter und GitHub
[email protected] und [email protected]

@Carreau Interesse an so etwas?

Diese Vorgehensweise wurde bereits 2013 etwas diskutiert und AFAICT verpönt als:

  • Sie müssen %%markdown in jeder Sprache neu implementieren
  • es erfordert eine Berechnung auf der Kernel-Seite, um Text anzuzeigen
  • es ändert die semantische Bedeutung des Renderns eines Markdowns.
  • versaute nbconvert --to markdown und nbconvert --to script
  • verkorkste Notebooks importieren Haken.

Das bricht die Semantik des Notebooks (IMHO), denn dann hängt der Text der "Markdown"-Zellen vom Kernel-Zustand ab. Also, während es süß ist, werde ich diese Idee ablehnen.

Auch die %%markdown , %%latex , %%javascript ... usw. wurden zu der Zeit geschrieben, als wir diese Diskussion führten.

Ich werde anmerken, dass es ähnliche Magien schon seit geraumer Zeit gibt und weitaus fortgeschrittenere Funktionen als nur die Verwendung von %%markdown .

Mein Denken hat sich im Laufe der Zeit weiterentwickelt und ich mag die Idee von @gnestor .

Wenn ein Benutzer per Definition Variablen aus dem Kernel in der Markdown-Zelle haben möchte,
diese Markdown-Zelle hängt vom Kernel ab. Sagen "das bricht die
Semantik des Notebooks" ist, als würde man sagen, wir sollten keine Codezellen zulassen
weil sie auf dem Kernel laufen und eine Ausgabe zurückgeben. Einer der Hauptzwecke
des Notebook-Dokuments soll als Aufzeichnung dessen dienen, was der Kernel tut.
Die Implementierung auf jedem Kernel, der Rich-Output unterstützt, ist trivial und es
das bricht alles stromabwärts (nbconvert, import Hooks) dann diese Dinger
haben Fehler (Markdown-Ausgabe ist bereits eine Sache).

Aber es geht mir gut, dies außerhalb des Ipython-Kernels zu tun ...

Am Do, 27.04.2017 um 10:29 Uhr, Matthias Bussonnier <
[email protected]> schrieb:

@Carreau https://github.com/Carreau Haben Sie Interesse an so etwas?

Diese Vorgehensweise wurde schon 2013 etwas diskutiert und
AFAICT wurde verpönt als:

  • Sie müssen %%markdown in jeder Sprache neu implementieren
  • es erfordert eine Berechnung auf der Kernel-Seite, um Text anzuzeigen
  • es ändert die semantische Bedeutung des Renderns eines Markdowns.
  • vermasseln nbconvert --to markdown und nbconvert --to script
  • verkorkste Notebooks importieren Haken.

Das bricht die Semantik des Notebooks (IMHO), denn dann ist der Text von
die "Markdown"-Zellen hängen vom Kernel-Zustand ab. Also, während es süß ist, gehe ich
diese Idee abzulehnen.

Auch die %%markdown, %%latex, %%javascript ... etc Magie wurden geschrieben an
die Zeit, als wir diese Diskussion führten.

Ich werde anmerken, dass es ähnliche Magien schon seit geraumer Zeit gibt
https://gist.github.com/bj0/5343292 und weitaus fortschrittlichere Funktionen als
Verwenden Sie nur %%markdown, also beeilen Sie sich bitte nicht, weil Sie so fertig sind
Sie sind dieser Idee noch nie begegnet.


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ipython/ipython/issues/2958#issuecomment-297784026 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AABr0HU-Gb3ENSidykbte53geYqPpy-sks5r0NCAgaJpZM4AchzX
.

--
Brian E. Granger
Assoziierter Professor für Physik und Datenwissenschaft
Cal Poly State University, San Luis Obispo
@ellisonbg auf Twitter und GitHub
[email protected] und [email protected]

Ich denke, dies ist der richtige Weg (Rendern von Markdown von Python

Nur zur Klarstellung, da ich Ihre Aussage anfangs falsch gelesen habe - dies verwendet den Kernel, um Markdown um Markdown in HTML zu

Ich mag diesen Ansatz. Wenn Sie einen einfachen Markdown wünschen, der den Kernel-Status beinhaltet, verwenden Sie den Kernel, um diesen Markdown anzuzeigen. Wenn Sie möchten, dass dieser Markdown live aktualisiert wird, verwenden Sie ein Widget (Sie könnten ein OutputWidget verwenden, oder wir könnten ein MarkdownWidget ähnlich dem HTMLWidget erstellen). Dies, begleitet von einfachen Möglichkeiten zum Ein- und Ausblenden von Eingaben und Ausgaben, macht für mich sehr viel Sinn.

Bin gerade auf dieses Ticket gestoßen und möchte erwähnen, dass auch SoS den oben genannten Ansatz verfolgt hat, nämlich Markdown vom Kernel zu rendern. Grundsätzlich implementiert sos eine %render Magie , die den Standard einer Zelle in MD (standardmäßig), HTML usw. rendert, und da sos verschiedene Sprachen unterstützt, rendert es auch die Ausgabe von jedem Subkernel, den es startet.

Hier ist eine einfache Lösung: https://github.com/jupyter/nbconvert/issues/320

Es wäre schön, wenn das, was auch immer passiert, auch mit RMarkdown kompatibel sein könnte. Das nutzt

 Der Wert von x ist `rx`.

Wobei x eine Variable in R ist.

https://github.com/vatlab/markdown-kernel ist nicht unbedingt das, was Sie brauchen, aber es unterstützt Rmarkdown-Zellen in einer Jupyter-Umgebung.

TL;DR: ist dieser Thread noch aktuell? JupyterLab hat keine direkte Lösung, aber Notebook schon? (2020)

Also ... diesen Thread zu lesen und die verschiedenen vorgeschlagenen Hacks auszuprobieren ... es scheint, dass diese Funktion ab 2020 in JupyterLab (zu der die Hauptseite die Leute seit mehreren Jahren drängt?) immer noch unmöglich / fehlt?), es sei denn, Sie verwenden SoS (alle anderen Problemumgehungen scheinen entweder nur Notebooks zu sein, dh veraltet/unbrauchbar für moderne Installationen ... oder erfordern den größten Teil des Komforts der Verwendung von Jupyters "Code + Markdown"-Kernfunktionalität).

Gibt es etwas, das ich verpasst habe? Es scheint, als ob das HauptjupyterLab (Anmerkung: nicht Notebooks, die gut funktionieren, und ich fühle mich ein bisschen betrogen, dass das Hauptprojekt Lab so stark antreibt, wenn Notebooks selbst jetzt im Jahr 2020 deutlich besser funktionieren) im Wesentlichen keinen Abschlag in docs für alles andere als trivial, nicht-analytisch, Beispiele - rhetorisch gesprochen: Was bringt es, ein Formatierungssystem in ein Datenanalyseprodukt einzubinden, wenn Sie Ihre Daten nicht mit der Formatierung ausgeben können?

Das scheint so falsch zu sein, dass ich denke, dass ich etwas grundlegendes übersehen haben muss. "SoS + Markdown-Kernel" fühlt sich an wie ein Vorschlaghammer, um eine Walnuss zu knacken, aber da funktioniert es ...

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen