PEP 762 – REPL-acing the default REPL
peps.python.org
PEP 762 – REPL-acing the default REPL
1–10 of 88 posts
Re: PEP 762 – REPL-acing the default REPL
#2I feel like there’s a missing discussion as to why they aren’t going with Ipython
Re: PEP 762 – REPL-acing the default REPL
#3I feel like there’s a missing discussion as to why they aren’t going with Ipython
they did acknowledge some alternatives, but I agree more discussion would have been nice.
FTA - Option 3: Using other existing REPL implementations: The authors looked at several alternatives like IPython, bpython, ptpython, and xonsh. While all the above are impressive projects, in the end PyREPL was chosen for its combination of maturity, feature set, and lack of additional dependencies. Another key factor was the alignment with PyPy’s implementation.
Re: PEP 762 – REPL-acing the default REPL
#4I feel like there’s a missing discussion as to why they aren’t going with Ipython
they did acknowledge some alternatives, but I agree more discussion would have been nice. FTA - Option 3: Using other existing REPL implementations: The authors looked at several alternatives like IPython, bpython, ptpython, and xonsh. While all the above are impressive projects, in the end PyREPL was chosen for its combination of maturity, feature set, and lack of additional dependencies. Another key factor was the…
IPython is huge: 15,5 Mo without any extras.
Python is 150mo. Hard to justify that 10% of the lines of code, source of bugs and maintenance only go to the shell.
Re: PEP 762 – REPL-acing the default REPL
#5I feel like there’s a missing discussion as to why they aren’t going with Ipython
I think the issue with iPython is that it's really quire large and has a non-trivial number of third-party dependencies that would need to be dealt with.
Python already has a million libraries built in, adding more in would be a pain. Plus there is the politics of making something "core" when the maintainers aren't part of the core python team.
Re: PEP 762 – REPL-acing the default REPL
#6I feel like there’s a missing discussion as to why they aren’t going with Ipython
Would be interesting to their reasons, but I'd be surprised if they had chosen it. I freaking love ipython, but it has a bunch of dependencies and extends far beyond just being a repl for the language and introduces things like magic commands, execute as shell, fallback logic etc.
Given how tight python keeps it's standard library, it seems pretty much imposssible to imagine those kind of advance features being developed while providing the stability that python normally asks from it's standard library.
Re: PEP 762 – REPL-acing the default REPL
#7I feel like there’s a missing discussion as to why they aren’t going with Ipython
[deleted]
Re: PEP 762 – REPL-acing the default REPL
#8I feel like there’s a missing discussion as to why they aren’t going with Ipython
I'm sure it's for exactly the same reason that I'm often hesitant to install it - huge dependencies:
$ pip show ipython
[...]
Requires: appnope, backcall, decorator, jedi, matplotlib-inline, pexpect, pickleshare, prompt-toolkit, pygments, stack-data, traitletsRe: PEP 762 – REPL-acing the default REPL
#9I feel like there’s a missing discussion as to why they aren’t going with Ipython
I'm sure it's for exactly the same reason that I'm often hesitant to install it - huge dependencies: $ pip show ipython [...] Requires: appnope, backcall, decorator, jedi, matplotlib-inline, pexpect, pickleshare, prompt-toolkit, pygments, stack-data, traitlets
Also, I'm genuinely thrilled to see cross-pollination from pypy back to cpython, so am actually really glad they did it this way - as cpython's JIT becomes production-ready, maybe more bits of python will become be self-hosting?
Re: PEP 762 – REPL-acing the default REPL
#10I feel like there’s a missing discussion as to why they aren’t going with Ipython
I'm sure it's for exactly the same reason that I'm often hesitant to install it - huge dependencies: $ pip show ipython [...] Requires: appnope, backcall, decorator, jedi, matplotlib-inline, pexpect, pickleshare, prompt-toolkit, pygments, stack-data, traitlets
Also, jedi depends on parso. Parso does not yet support `match` (which is a big problem for me, as it means I need to switch AST library backing mutmut).