[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to buil
From: |
Jack Kamm |
Subject: |
Re: [DISCUSSION] Should we deprecate python-mode.el (alternative to built-in python.el) support in ob-python? |
Date: |
Fri, 27 Jan 2023 15:13:50 -0800 |
Ihor Radchenko <yantar92@posteo.net> writes:
> Let's follow the usual approach and first deprecate it. It should become
> a constant with 'python value in org-compat.el. Deprecating is not make
> sure that other packages that might be testing the variable value do not
> get broken.
>
> Note that we usually `quote' Elisp symbols in the commit messages.
Thank you for the review. I've incorporated your feedback and pushed
the patch as commit aa48c80fe17eaaaf83c11c9ac2f2fd864f2f3ad9
> I find the need to use advise awkward. Is it necessary?
I agree it is awkward, and also fragile to future changes in ob-python.
But unless I've missed something, I think some advice is needed to get
the old behavior. Still, it would be more robust to just advise the
main function org-babel-execute:python, instead of advising the 2
helper functions.
But, this would require a little extra work, and while I might do it
later, it's a lower priority for me right now (it's unclear whether
there are currently active python-mode users of ob-python). For the
moment, I just updated the Readme to say the current implementation is
a temporary workaround, and it will work for Org 9.7, but may not work
in future versions as ob-python evolves.
Arguably, it would be best to avoid overriding python src blocks
altogether, and instead have completely separate python-mode src
blocks. But I would leave such a design decision to whoever decides to
maintain babel+python-mode integration in future.