bug#51196: 29.0.50; python.el eldoc problems

[Carlos Pita <carlosjosepita2@gmail.com>]

Hi Augusto,

> I see.  I never noticed this because Eglot masks the completion/eldoc
> functions from python.el.

I guess this is often the case. There are some scenarios in which you
mainly interact with your interpreter from a python buffer (as in your
code-cells) for which naive (not naTive :) ) runtime completion with
no static inference bells and whistles may still be desirable. IIRC
elpy has some kind of fallback from jedi completion to runtime
completion fed by the inferior interpreter. elpy also implements a
small rpc mechanism for all this stuff, so it doesn't share the
shortcomings of python.el while still not requiring a full-fledged
static analyzer. Sadly elpy is in low-maintenance mode now.
emacs-jupyter also gets this right when completing from its inferior
kernels, it even provides a minor mode that is able to pull off its
magic inside org babel blocks! Anyway, static analyzers are getting
better every day and the point of runtime completion is in turn
getting mooter every day, except perhaps in that it still is the more
lightweight alternative.

> As you already mentioned, the biggest problem here is to use the same
> Python process/thread for both REPL interaction _and_
> completion/documentation stuff.

Yes, there are race conditions between emacs and its user, to put it somehow.

> > But that's not true of non-native completion AFAICS and
> > it certainly isn't of C-c C-f (help on symbol).
>
> If the user explicitly types C-c C-f, then I see no problem in the
> blocking behavior.

I don't think we can ask the user to remember checking its inferior
process before requesting quick help on a symbol and, anyway, we don't
need to agree on this because after fixing the implicit cases
this one will follow suit for free.

I'm about to retire in a few months and I will have the time to
undertake a slightly more ambitious change regarding these rough edges
of python.el, but I won't start without some level of consensus around
the issues and the solution. After that, I wouldn't mind doing some
maintenance of the module.

Best regards,
Carlos