On 26 October 2016 at 09:15, Nathaniel Smith <n...@pobox.com> wrote: > Incidentally, PyPy's built-in REPL handles multi-line constructs like > IPython does, rather than like how the CPython built-in REPL does. > > There are a lot of logistic issues that would need to be dealt with > before CPython could consider making a third-party REPL the default or > anything like it... it looks like IPython's dependency tree is all > pure-Python, which makes it more viable, but it's still a lot of code > and on a very different development cycle than CPython. bpython > appears to depend on greenlet, which is a whole other issue... OTOH it > seems a little quixotic to spend lots of resources improving the > built-in REPL when there are much better ones with vibrant developer > communities.
The built-in REPL serves two quite divergent use cases, and I think we're well past the point where we can't readily support both use cases with a single implementation: - a minimalist interactive environment, that is *always* present, even if parts of the interpreter (most notably the import system) aren't working or have been deliberately disabled - a day-to-day working environment for Python developers The prevalence of the latter use case then leads to it also being used as a tool for introducing new developers to Python. The problem is that of these two use cases, the current default REPL is really only *good* at the first one - for the latter, it's instead only "frequently good enough", since there are much better alternatives out there that can depend on the whole Python ecosystem rather than having to make the assumption that they should still basically work even if the import system isn't currently set up to bring in external modules. One possible path towards improving the situation might be to look at the PyPy REPL (which is presumably implemented in RPython) and see if that would be suitable for incorporation into CPython as a frozen module (perhaps with some modifications). That has the advantage of making the REPL much easier to iterate on (since you can use the non-frozen version for development), while still making it available at runtime as part of the core Python binary. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
