Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 762 – REPL-acing the default REPL

peps.python.org

Post reply on HN
Print view View original

41–50 of 88 posts

Re: PEP 762 – REPL-acing the default REPL

#41

Post by HellsMaddy »

wiseowise wrote: post #36

> The new REPL released in Python 3.13 aims to provide modern features No `vi` mode and not planned. Very modern. https://github.com/python/cpython/issues/118840

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.

Re: PEP 762 – REPL-acing the default REPL

#42

Post by halfcat »

behnamoh wrote: post #11

I want a Lisp-like REPL for my Python programs that is available to the user who runs my compiled Python program (so, I want compilation as well). The user will be able to interact with my program (instead of just running the main function), change function definitions, etc. and mold the program to their specific use case while it's running.

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.

Re: PEP 762 – REPL-acing the default REPL

#44

Post by IshKebab »

wiseowise wrote: post #36

> The new REPL released in Python 3.13 aims to provide modern features No `vi` mode and not planned. Very modern. https://github.com/python/cpython/issues/118840

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.

Re: PEP 762 – REPL-acing the default REPL

#45

Post by zahlman »

12_throw_away wrote: post #8
wodenokoto wrote: post #2

I 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

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.

Re: PEP 762 – REPL-acing the default REPL

#46

Post by zahlman »

behnamoh wrote: post #11

I want a Lisp-like REPL for my Python programs that is available to the user who runs my compiled Python program (so, I want compilation as well). The user will be able to interact with my program (instead of just running the main function), change function definitions, etc. and mold the program to their specific use case while it's running.

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

Re: PEP 762 – REPL-acing the default REPL

#47

Post by Y_Y »

ks2048 wrote: post #24
behnamoh wrote: post #18

Earlier quoted context omitted.

Lisp REPL keeps the state of the program because it is a live image. With Python REPL you need to rerun the program to set the variables to their values.

You can create a file, example.py: import time value = "foo" def go(): for i in range(10): print("...", i, value) time.sleep(3) Then, in repl, import example import threading thread = threading.Thread(target=example.go) thread.start() It will slowly print out messages and you can do "example.value = 'bar'" in the REPL and it will change.

That's a nice trick!

For reference, what I'd normally do if I wanted that is specify launching with the debugger, like

    python3 -mpdb example.py
and then step through. Also `ipdb` is nice if available.

Re: PEP 762 – REPL-acing the default REPL

#48

Post by zahlman »

behnamoh wrote: post #25
ks2048 wrote: post #24

Earlier quoted context omitted.

You can create a file, example.py: import time value = "foo" def go(): for i in range(10): print("...", i, value) time.sleep(3) Then, in repl, import example import threading thread = threading.Thread(target=example.go) thread.start() It will slowly print out messages and you can do "example.value = 'bar'" in the REPL and it will change.

it's not the same though—In Lisp, when you compile your program, a Lisp run-time is attached to it so you can either run the program normally (like any binary) or you could REPL into the program and see what the values of variables are (these values were set at compile time). This is helpful when you have a large dataset you don't want to load over and over.

Have you tried out the Python standard library debugger (pdb)?

Re: PEP 762 – REPL-acing the default REPL

#49

Post by zahlman »

klreslx wrote: post #12

I don't see the point. People who want Jupyter or an IDE know where to find it. Other people who want the basic REPL and mostly use editors anyway are annoyed. Well, perhaps the usual suspects can get another infoworld self-promotion article out of it.

They really don't. The Python userbase has a very high percentage of beginners at any time, and trying to move them into Jupyter or an IDE before they understand fundamentals, usually just makes it much harder to help them with programming problems (because they don't know what's language functionality and what comes from their tools; they don't know anything about the virtual environment the tool is managing; they aren't prepared for an IDE to identify problems that are different from what the runtime chokes on; etc.)

The basic REPL causes serious problems for beginners, and the differences in this REPL are (intentionally or not) largely geared towards fixing those problems. Most notably, beginners can't reliably paste in code examples from tutorials. Either there's a use of `input` which eats the next line of code as interactive input, or a blank line inside a block which the REPL interprets as end-of-code (causing the rest of the block to report `IndentationError`s despite being correctly indented for the intent of the code). They also commonly get tripped up by `help` and `exit` being Python callables rather than REPL commands, and get put off by the lack of built-in screen clearing. (Historically - as it turns out from forum discussion - the Python devs have expected that people actually quit the interpreter with ctrl-D/ctrl-Z, and clear the screen with the terminal emulator's functionality for doing so.)

Re: PEP 762 – REPL-acing the default REPL

#50

Post by zahlman »

itishappy wrote: post #40
tqnwx wrote: post #38

Earlier quoted context omitted.

Not the one you are asking, but NumPy literally converted to meson because of the deprecation. There was tons of pain for so many extensions. This pain generates job security for the bigcorp employees and grief for anyone else.

Super helpful, thanks! The NumPy page on the migration has some details on the differences: > ... [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 suppor…

I never did understand this. It appears that they were maintaining their own fork of distutils anyway (and if you open up a latest-version wheel today you should still see it included); so why did the standard library removal cause a problem?
Post reply on HN