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

51–60 of 88 posts

Re: PEP 762 – REPL-acing the default REPL

#51

Post by zahlman »

rgollert wrote: post #17
influx wrote: post #14

Earlier quoted context omitted.

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

The same people removed distutils, which is why at my company we had to update several internal C-extensions. In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.

>The same people removed distutils

Yes; it's extremely cruft-filled and nobody wanted to / had the skills to keep the standard library version maintained. There's a note in the Setuptools documentation somewhere about how distutils was deemed fundamentally unfixable, and it doesn't come across like the hacks Setuptools was applying on top of distutils were particularly well understood by anyone.

>In these decisions the only thing that matters is if Microsoft, Facebook, Bloomberg or one of their employees is pleased.

I don't think there's good evidence for this, and the current case is certainly not convincing. Why would they want distutils removed - as opposed to that motivation come from the devs who would otherwise be responsible for its bugs?

Re: PEP 762 – REPL-acing the default REPL

#52

Post by zahlman »

Numerlor wrote: post #26
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.

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

I've never actually used these industrial-strength "containers" before, but I had understood that they're supposed to be primarily for deployment, or at least some automated testing step in a big CI system. Why would the REPL come into play for these use cases?

Re: PEP 762 – REPL-acing the default REPL

#53

Post by AcerbicZero »

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 out that Powershell still has one of the best ISE's/IDE's in the game for this kind of stuff. One window for editing, a terminal in which whatever you edit runs, and then access to every var/function/etc you just touched in that same terminal is a joyous experience that is shockingly hard to recreate for many languages. Hell half the time I'm just testing out random syntax or a portion of a function and being able to do that in the same session as the script I'm working is awesome.

With enough abuse VS code comes close (for Ruby at least, thank you Pry!) but it would be nice to get a similar experience with Python; I've used a few of the existing REPL options for python, but most of them require you to actually figure out pdb and even then it wasn't as tightly integrated as what I actually wanted.

Re: PEP 762 – REPL-acing the default REPL

#54

Post by wodenokoto »

BiteCode_dev wrote: post #34
somat wrote: post #28

Earlier quoted context omitted.

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)

yeah sorry mb, french comming out

OT, but I love your newsletter!

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

Re: PEP 762 – REPL-acing the default REPL

#55

Post by zem »

cycomanic wrote: post #19
Miniminix wrote: post #3

Earlier quoted context omitted.

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…

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 th…

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

Re: PEP 762 – REPL-acing the default REPL

#56

Post by wodenokoto »

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

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

Re: PEP 762 – REPL-acing the default REPL

#57

Post by 0cf8612b2e1e »

zahlman wrote: post #45
12_throw_away wrote: post #8

Earlier quoted context omitted.

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.

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’

Re: PEP 762 – REPL-acing the default REPL

#58

Post by d0mine »

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.

Repl can be attached to a live python process (you don't need to restart anything)

https://stackoverflow.com/questions/1395913/how-to-drop-into...

You could do it even without cooperation from the python app using approach similar to pyrasite (though it is much easier with cooperation--just add a couple of lines).

Re: PEP 762 – REPL-acing the default REPL

#59

Post by cozzyd »

itishappy wrote: post #39
cozzyd wrote: post #35

Earlier quoted context omitted.

The deprecation of distutils caused a ton of havoc for e.g. FreeCAD

I won't argue with that, but I would like to understand why. If I'm on the right path with these forum threads, it looks like there were issues with how Debian packages python? https://forum.freecad.org/viewtopic.php?t=67985 https://github.com/FreeCAD/FreeCAD/pull/6753 https://ffy00.github.io/blog/02-python-debian-and-the-instal...

I don't know the details, all I know is because of that I can't currently install FreeCAD from Fedora repositories which is super annoying, and IMO not the fault of either Fedora or FreeCAD...

Re: PEP 762 – REPL-acing the default REPL

#60

Post by zahlman »

Now that I've actually gone and read the PEP instead of just relying on my familiarity with the changes as described elsewhere (and experienced for myself):

... Wow, significant portions of that come across to me as AI-generated. I'm pretty sure this is the first time I've gotten that impression from a PEP.

Post reply on HN