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

61–70 of 88 posts

Re: PEP 762 – REPL-acing the default REPL

#61

Post by zahlman »

AcerbicZero wrote: post #53

I have been "advocating" (i.e. complaining) for better REPLs basically the entire time I've been writing code - One of my favorite pasttimes is getting all flustered and trying to throw enough extensions and custom code to get an offline REPL.it style experience out of VS Code for whatever language I'm playing with at the moment, and lately its kinda been working (for Ruby, at least). I am also very found of pointing…

I usually just have one terminal window open with the Python REPL, and another open with a text editor. Works fine for me, although admittedly it was slightly more convenient back when `reload` was a builtin. (That's maybe the one thing I miss from 2.x, if I had to pick one. Sure, it doesn't honestly really make sense as a builtin; but it could have been added to `site` or something.)

Re: PEP 762 – REPL-acing the default REPL

#62

Post by Macha »

o11c wrote: post #21
wodenokoto wrote: post #2

I feel like there’s a missing discussion as to why they aren’t going with Ipython

The horrible startup time is probably part of it: $ time ipython3 -c 'pass' real 0m1.083s user 0m0.355s sys 0m0.093s

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.

Re: PEP 762 – REPL-acing the default REPL

#63

Post by o11c »

Macha wrote: post #62
o11c wrote: post #21

Earlier quoted context omitted.

The horrible startup time is probably part of it: $ time ipython3 -c 'pass' real 0m1.083s user 0m0.355s sys 0m0.093s

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.

Re: PEP 762 – REPL-acing the default REPL

#64

Post by Sohcahtoa82 »

IshKebab wrote: post #44
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.

vi fanatics are a weird bunch.

Knowing how to use vi can be useful, but I absolutely cannot fathom how someone can prefer it over an actual IDE as their daily driver for writing code. What's especially disappointing is how often they say things like "I like vi because I can do X" and every time, without fail, X is something any reasonable IDE has been able to do for 10+ years.

No idea why they're so fascinated by using letter keys to move around rather than arrows, as if it takes significant effort to slide you hand 6 inches. You do it often enough and you can go back and forth without even looking.

Re: PEP 762 – REPL-acing the default REPL

#65

Post by banku_brougham »

zahlman wrote: post #61
AcerbicZero wrote: post #53

I have been "advocating" (i.e. complaining) for better REPLs basically the entire time I've been writing code - One of my favorite pasttimes is getting all flustered and trying to throw enough extensions and custom code to get an offline REPL.it style experience out of VS Code for whatever language I'm playing with at the moment, and lately its kinda been working (for Ruby, at least). I am also very found of pointing…

I usually just have one terminal window open with the Python REPL, and another open with a text editor. Works fine for me, although admittedly it was slightly more convenient back when `reload` was a builtin. (That's maybe the one thing I miss from 2.x, if I had to pick one. Sure, it doesn't honestly really make sense as a builtin; but it could have been added to `site` or something.)

ptpython is great in this usage

Re: PEP 762 – REPL-acing the default REPL

#66

Post by handman »

zahlman wrote: post #49
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 a…

[flagged]

Re: PEP 762 – REPL-acing the default REPL

#67

Post by handman »

zahlman wrote: post #50
itishappy wrote: post #40

Earlier quoted context omitted.

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?

Because the "fork" still relied on the presence of the included distutils.

Re: PEP 762 – REPL-acing the default REPL

#68

Post by handman »

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.

This is nothing like the Lisp debugger. It is very hard to convince Pythonistas of the fact:

https://news.ycombinator.com/item?id=36888648

Re: PEP 762 – REPL-acing the default REPL

#69

Post by ks2048 »

handman wrote: post #68
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.

This is nothing like the Lisp debugger. It is very hard to convince Pythonistas of the fact: https://news.ycombinator.com/item?id=36888648

Interesting thread. I only read some of it, but I did find one answer that tells me how Python and LISP differ:

  As an example, I suppose that when you’re developing code in Python’s pseudo-REPL you often reimport a file containing class definitions. When you do that, what happens to all the old objects with the old  class definition? Nothing, they still belong to the old class.

  ...

  In Lisp, it’s different. There is a defined protocol for what happens when a class is redefined. Every single object belonging to the old class gets updated to the new class.

Re: PEP 762 – REPL-acing the default REPL

#70

Post by krick »

benrutter wrote: post #6
wodenokoto wrote: post #2

I 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 devel…

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.

Post reply on HN