PEP 762 – REPL-acing the default REPL

I 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.

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.

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.

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.

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?

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).

I just tested installing ipython and it came with 17 dependencies. Some of which are probably pretty heavy and/or way too in flux to make it into the standard library.

I think ptpython would have been a much better choice. It is relatively small with few dependencies, much more feature complete, importantly it can run in windows terminal AFAIK which pyrepl can't at the moment. I suspect it has also seen much more testing because it is much more widely used.

This really seems like a missed opportunity, instead of another repl that will only be used by developers (they even stated that as primary motivation) who can't install anything else, they could have taken a repl that would actually be widely used to integrate into other programs... Instead I suspect pyrepl will eventually experience the same fate as the current repl, i.e. it will languish with no development and get replaced again eventually because it has become to painful to adjust to changes in the rest of the language and changes in terminals.

The horrible startup time is probably part of it:

  $ time ipython3 -c 'pass'
  real    0m1.083s
  user    0m0.355s
  sys     0m0.093s

I am curious about your suffixes.

I mean, I understand the post fine, but I have never seen the units (Mo, mo) before and am wondering where they came from.

I would guess mo is megabytes(megaoctets?) and Mo is gigabytes(is ipython really 15GB? yikes)

Looks like it’s octets: https://en.m.wikipedia.org/wiki/Octet_(computing)

I think I remember seeing something about MB=Mo in french, the casing is probably safe to ignore in the gp as ipython is definitely not 15gb

yeah sorry mb, french comming out

My guess is that it's not really designed to be fully severed from Jupyter. It certainly shouldn't require Matplotlib to run a console REPL.

OT, but I love your newsletter!

Didn’t notice your username until you wrote “French”

fewer dependencies than ipython perhaps, but still unacceptable for something that needs to be shipped as part of the language. also I feel that you are unduly pessimistic about its chances and that the PEP is right about this one - being written in python rather than C will get it a ton of contributions from the community if anything is found lacking. particularly since you won't necessarily need to know a ton about python internals to just contribute to the repl

While I haven’t figured out how, it is my understanding that there exists a workflow where you have ipython/jupyter installed once, and then have them use the Python interpreter and modules associated with each project.

But I’ve never figured it out and instead have a `requirements-dev.txt` with Jupyter and Ipython in every project because they are so good to have on hand when developing

I am pretty sure matplotlib is not required. That is just a convenience library that improves the notebook experience if matplotlib is loaded. So you no longer need to run the magic function ‘%matplotlib inline’

Is this worse than the standard python interpreter? Python startup time is a big reason I've moved a bunch of my personal utilities to Rust.

CPython startup is pretty fast assuming you aren't importing heavy modules. Of course, any nontrivial program needs to do some imports.

Some examples:

  0.01s cpython - with site disabled
  0.04s pypy - with site disabled
  0.04s cpython - import site and/or built-in modules
  0.08s pypy - import site and/or built-in modules
  0.13s cpython - import requests  
  0.31s pypy - import requests
  0.31s cpython - import IPython
  0.72s pypy - import IPython
  1.1s cpython - run ipython nop
  2.1s pypy - run ipython nop

(the last digit of all of these numbers often varies a little)

Since Python's startup is reasonably fast, it's possible to use it for interactive tools even with heavy imports by spawning a daemon the first time, and just forwarding the requests over a socket. This is mildly annoying but not particularly difficult.

That's fair. But I wonder if developing a "better REPL" won't be essentially a bug-ridden implementation of half of the ipython. Like that lisp joke...

So I don't know if community work to de-couple ipython into "essential" and "jupyter-stuff" is any viable, but I'd really consider it before committing to write the same thing (but worse) from scratch.

If I remember correctly, unlike the standard Python interpreter, ptpython does not support the replacement of sys.excepthook by a custom one. I know that I look at seeing if I could have it support friendly-traceback but couldn't.

That's lovely to hear.

It's great hearing it in general, but given the HN community is picky, it feels even better.