Jack Kamm writes:
> Liu Hui writes:
>
>> I think these objects need to be shown in a single column rather than
>> two. Besides, if the python code becomes too complex finally, I think
>> maintaining the python code outside the ob-python.el, as suggested by
>> Ihor, is a good idea.
>
> Thanks
Ihor Radchenko writes:
> +1
> Don't forget to update
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html
> (note how the docs already have an example of org formatting from python)
Thanks! Done now:
> Thanks for reporting these misbehaving examples. I think the root of the
> problem is `org-babel-script-escape', which is too aggressive in
> recursively converting strings to lists. We may need to rewrite our own
> implementation for ob-python.
>
> Also, I agree that moving the python code to
Liu Hui writes:
> I think these objects need to be shown in a single column rather than
> two. Besides, if the python code becomes too complex finally, I think
> maintaining the python code outside the ob-python.el, as suggested by
> Ihor, is a good idea.
Thanks for reporting these misbehaving
Jack Kamm writes:
> In the meantime, I'm thinking to squash and apply my patch as is. Then
> afterwards, I can start working on a followup patch to move some Python
> code into a separate file (and coordinate with emacs-devel if
> necessary).
+1
Don't forget to update
Jack Kamm writes:
> Ihor Radchenko writes:
>
>> Similar to the existing LaTeX formatters, one may write a Python package
>> that will pretty-print Org markup as text.
>
> This sounds interesting -- are these LaTeX formatters external to Org?
> Could you provide a link/reference?
Ihor Radchenko writes:
> We might add the code into a separate proper python file. Then, we can
> use the contents of that file to retrieve the variable value.
>
> We already do the same thing for CSL style files and odt schema/style.
Thanks, I think this is a good idea, and will make the
Ihor Radchenko writes:
> Similar to the existing LaTeX formatters, one may write a Python package
> that will pretty-print Org markup as text.
This sounds interesting -- are these LaTeX formatters external to Org?
Could you provide a link/reference?
> > Here we can use '{}'.format(df.index.name) to show the name of index
>
> Patch has been updated to print the index name when it is non-None.
Thanks! It would be nice to also support MultiIndex names using
`result.index.names', e.g.
#+begin_src python :results table
import numpy as np
import
Jack Kamm writes:
> As to the broader point, I agree there are many more features that would
> be nice to add ob-python results handling. But making ob-python too
> complex will be difficult to maintain, especially since the Python code
> is all in quoted strings without proper linting.
We
Jack Kamm writes:
>> What about :results graphics file ?
>
> Not entirely sure what you mean here.
Never mind. I was mixing the meaning of header args in my mind after all
the previous discussions.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at
Jack Kamm writes:
> So I am thinking now about how we could make this more extensible in
> future. One idea is to create a Python package for interfacing with Org
> Babel, and release it on PyPi. If we detect the package is installed,
> then we can delegate to it for results formatting. And the
gerard.vermeu...@posteo.net writes:
> I do not know how much this "abuse" of defconst is frowned
> upon (elisp manual says defconst is advisory), but maybe it
> can be advertised as a feature.
org-babel-python--def-format-value is a "private" variable (it has
double dash "--" in its name).
Ihor Radchenko writes:
> This is an ORG-NEWS entry for Version 9.4. Is it an intentional change?
Sorry, that was an accident. I've reverted it now:
https://github.com/jackkamm/org-mode/commit/f12a695d67bc5c06013d9fbe0af844c9739e347a
>> @@ -142,7 +144,9 @@ (defun
Liu Hui writes:
> Hi,
>
> Thank you for the patch!
Thanks for your feedback, I've incorporated it into
https://github.com/jackkamm/org-mode/tree/python-results-revisited-2023
More specifically, here:
https://github.com/jackkamm/org-mode/commit/af1d18314073446045395ff7a3d1de0303e92586
> Do we
Ihor Radchenko writes:
>>> #+begin_src python :results list
>>>return {"a": 1, "b": 2}
>>> #+end_src
>>>
>>> #+RESULTS:
>>> - a :: 1
>>> - b :: 2
>>
>> This seems harder, and may require more widespread changes beyond
>> ob-python. In particular, I think we'd need to change
>>
On 18.08.2023 06:37, gerard.vermeu...@posteo.net wrote:
On 17.08.2023 14:10, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
Your patches allow anyone to change
org-babel-python--def-format-value.
For instance, I want to use black to "pretty-print" certain tree-like
structures
On 17.08.2023 14:10, Ihor Radchenko wrote:
gerard.vermeu...@posteo.net writes:
Your patches allow anyone to change
org-babel-python--def-format-value.
For instance, I want to use black to "pretty-print" certain tree-like
structures
May you simply add an extra code to transform output as
gerard.vermeu...@posteo.net writes:
> Your patches allow anyone to change org-babel-python--def-format-value.
> For instance, I want to use black to "pretty-print" certain tree-like
> structures
May you simply add an extra code to transform output as needed?
--
Ihor Radchenko // yantar92,
Org
Jack Kamm writes:
> I attach a 2nd patch implementing this. It also makes ":results table"
> the default return type for dict. (Use ":results verbatim" to get the
> dict as a string instead).
Thanks!
>> #+begin_src python :results list
>>return {"a": 1, "b": 2}
>> #+end_src
>>
>>
Jack Kamm writes:
> Following up on a discussion from last month [1], I am reviving my
> proposal from a couple years ago [2] to improve ob-python results
> handling. Since it's a relatively large change, I am sending it to the
> list for review before applying the patch.
Some comments on the
On 17.08.2023 06:04, Jack Kamm wrote:
I attach a 2nd patch implementing this. It also makes ":results table"
the default return type for dict. (Use ":results verbatim" to get the
dict as a string instead).
I am also putting a branch with these changes here:
Hi,
Thank you for the patch!
> Next, for numpy arrays and pandas dataframes/series: these are
> converted to tables, for example:
>
> #+begin_src python
> import pandas as pd
> import numpy as np
>
> return pd.DataFrame(np.array([[1,2,3],[4,5,6]]),
>
Ihor Radchenko writes:
> What about
>
> #+begin_src python :results table
>return {"a": 1, "b": 2}
> #+end_src
>
> #+RESULTS:
> | a | 1 |
> | b | 2 |
I attach a 2nd patch implementing this. It also makes ":results table"
the default return type for dict. (Use ":results verbatim" to
Jack Kamm writes:
> Starting with dicts: these are no longer mangled. The current behavior
> (before patch) is like so:
>
> #+begin_src python
> return {"a": 1, "b": 2}
> #+end_src
>
> #+RESULTS:
> | a | : | 1 | b | : | 2 |
>
> But after the patch they appear like so:
>
> #+begin_src python
>
f4x+s5m_...@mail.gmail.com/
[2] https://list.orgmode.org/87eenpfe77@gmail.com/
>From 468eeaa69660a18d8b0503e5a68c275301d6e6ae Mon Sep 17 00:00:00 2001
From: Jack Kamm
Date: Mon, 7 Sep 2020 09:58:30 -0700
Subject: [PATCH] ob-python: Results handling for dicts, dataframes, arrays,
plots
*
26 matches
Mail list logo
