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

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.

The horrible startup time is probably part of it:

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

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.

Honestly, even as a neovim user, I don’t find vi mode to be very ergonomic for interactive prompts, and I prefer emacs-style keybindings in these cases. The only time I feel the need for vi mode is when I want to copy something, but in that case I already have that capability through tmux copy-mode. I would prefer if the team prioritizes python-specific functionality first and foremost.

I will be staying on ptpython then.

Yeah it is. Vi is ancient and not at all modern or use friendly. Look at that bug report! They're complaining they can't go up to the previous command by pressing ESC k. Instead they have to press.... up. Ye gads.

>the user who runs my compiled Python program (so, I want compilation as well).

You'll be happy to know that Python .pyc files, which are created and cached by default, are the equivalent of Java's .class files or C#'s bytecode (which gets embedded inside an .exe wrapper but is still fundamentally not native code).

>The user will be able to... change function definitions, etc.

Of course, this requires recompilation in some form (in Lisp, too - `eval` is not that magic).

That said, if `import`ing your code at the REPL and then calling functions, setting attributes etc. (which has been possible in Python forever) isn't good enough, I really don't understand your use case.

Some things are a bit awkward, but what specifically can't you really do in a Python REPL? You can dynamically overwrite functions in an imported module, you can re-import modules with importlib, etc. I ask because my Lisp experience is limited.

    import time
    value = "foo"
    def go():
      for i in range(10):
        print("...", i, value)
        time.sleep(3)

    import example
    import threading
    thread = threading.Thread(target=example.go)
    thread.start()

    python3 -mpdb example.py

Go with Smalltalk instead. Not only do you get REPL-level interactivity[1], user actions are also automatically persisted, and it works with a GUI by default! With Glamorous Toolkit (a Pharo Smalltalk-based IDE) you even get good interop with Python out of the box. Really, if you have users who would benefit from being able to interact with your code directly, Smalltalk is THE way to go :) Ofc, the problem is finding such users in the first place...

[1] As Smalltalk is most often used with GUIs, you don't get a "REPL" by default - instead, anywhere you can enter text, you can right-click and execute that text as code. You can code a real REPL yourself if you want - 10 lines in the "on new line character" method in a generic text field and you're done.

Something like https://hylang.org/ ? I suppose it won't work with compiled code though.

I don’t know how this works with the compilation angle, but this is often a life saver:

  try:
    # problem
  except:
    import code
    code.interact(local=locals())

You can add globals() in addition to locals() if desired.

This drops you into the interactive shell and you can go wild. Even works inside interactive code like grabbing a live HTTP request or GUI event to see what’s going on.

If Python is going to include a REPL (which I think it should), it might as well include useful features that people expect from a modern REPL. (That being said, I personally always install ipython...)

Maaaybe color highlight can annoy some purist, but multiline edit and cursor movement are the bare minimum. Either add these features or get rid of the battery included Repl in favour of third parties.

There's a tremendous power with defaults and with "batteries included".

    > ... [Here] are the numpy.distutils features that are not present in setuptools:
      * Nested setup.py files
      * Fortran build support
      * BLAS/LAPACK library support (OpenBLAS, MKL, ATLAS, Netlib LAPACK/BLAS, BLIS, 64-bit ILP interface, etc.)
      * Support for a few other scientific libraries, like FFTW and UMFPACK
      * Better MinGW support
      * Per-compiler build flag customization (e.g. -O3 and SSE2 flags are default)
      * a simple user build config system, see site.cfg.example
      * SIMD intrinsics support
      * Support for the NumPy-specific .src templating format for .c/.h files

From my experience working with the default repl in e.g. a docker container is extremely frustrating comparing to ipython, and I don't want to be installing ipython and its multitude of dependencies everywhere