←back to thread

89 points Numerlor | 9 comments | | HN request time: 0.001s | source | bottom
Show context
wodenokoto ◴[] No.41846571[source]
I feel like there’s a missing discussion as to why they aren’t going with Ipython
replies(7): >>41848474 #>>41851105 #>>41851125 #>>41851190 #>>41851214 #>>41852161 #>>41852289 #
1. Miniminix ◴[] No.41848474[source]
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.

replies(2): >>41851065 #>>41852019 #
2. BiteCode_dev ◴[] No.41851065[source]
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.

replies(1): >>41852661 #
3. cycomanic ◴[] No.41852019[source]
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.

replies(1): >>41854073 #
4. somat ◴[] No.41852661[source]
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)

replies(3): >>41852757 #>>41852767 #>>41852931 #
5. mimischi ◴[] No.41852757{3}[source]
Looks like it’s octets: https://en.m.wikipedia.org/wiki/Octet_(computing)
6. Numerlor ◴[] No.41852767{3}[source]
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
7. BiteCode_dev ◴[] No.41852931{3}[source]
yeah sorry mb, french comming out
replies(1): >>41854067 #
8. wodenokoto ◴[] No.41854067{4}[source]
OT, but I love your newsletter!

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

9. zem ◴[] No.41854073[source]
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