4 ms·

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

Miniminix 2y ago
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.
- BiteCode_dev 2y ago
  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.
  - somat 2y ago
    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)
    - mimischi 2y ago
      Looks like it’s octets: https://en.m.wikipedia.org/wiki/Octet_(computing) https://en.m.wikipedia.org/wiki/Octet_(computing)
    - Numerlor 2y ago
      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
    - BiteCode_dev 2y ago
      yeah sorry mb, french comming out
      - wodenokoto 2y ago
        OT, but I love your newsletter! Didn’t notice your username until you wrote “French”
        BiteCode_dev 2y ago
        That's lovely to hear. It's great hearing it in general, but given the HN community is picky, it feels even better.
- cycomanic 2y ago
  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.
  - zem 2y ago
    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
  - aroberge 2y ago
    If I remember correctly, unlike the standard Python interpreter, ptpython does not support the replacement of sys.excepthook by a custom one. I know that I look at seeing if I could have it support friendly-traceback but couldn't.
KaiserPro 2y ago
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.
benrutter 2y ago
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.
- 0cf8612b2e1e 2y ago
  I just tested installing ipython and it came with 17 dependencies. Some of which are probably pretty heavy and/or way too in flux to make it into the standard library.
- krick 2y ago
  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.
deleted 2y ago
[deleted]
12_throw_away 2y ago
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
- 12_throw_away 2y ago
  Also, I'm genuinely thrilled to see cross-pollination from pypy back to cpython, so am actually really glad they did it this way - as cpython's JIT becomes production-ready, maybe more bits of python will become be self-hosting?
- boxed 2y ago
  Also, jedi depends on parso. Parso does not yet support `match` (which is a big problem for me, as it means I need to switch AST library backing mutmut).
- zahlman 2y ago
  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.
  - 0cf8612b2e1e 2y ago
    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’
- wodenokoto 2y ago
  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
o11c 2y ago
The horrible startup time is probably part of it: $ time ipython3 -c 'pass' real 0m1.083s user 0m0.355s sys 0m0.093s
- Macha 2y ago
  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.
  - o11c 2y ago
    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.
deleted 2y ago
[deleted]

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.

BiteCode_dev 2y ago
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.
- somat 2y ago
  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)
  - mimischi 2y ago
    Looks like it’s octets: https://en.m.wikipedia.org/wiki/Octet_(computing) https://en.m.wikipedia.org/wiki/Octet_(computing)
  - Numerlor 2y ago
    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
  - BiteCode_dev 2y ago
    yeah sorry mb, french comming out
    - wodenokoto 2y ago
      OT, but I love your newsletter! Didn’t notice your username until you wrote “French”
      - BiteCode_dev 2y ago
        That's lovely to hear. It's great hearing it in general, but given the HN community is picky, it feels even better.
cycomanic 2y ago
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.
- zem 2y ago
  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
- aroberge 2y ago
  If I remember correctly, unlike the standard Python interpreter, ptpython does not support the replacement of sys.excepthook by a custom one. I know that I look at seeing if I could have it support friendly-traceback but couldn't.

KaiserPro 2y ago

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.

benrutter 2y ago

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.

0cf8612b2e1e 2y ago
I just tested installing ipython and it came with 17 dependencies. Some of which are probably pretty heavy and/or way too in flux to make it into the standard library.
krick 2y ago
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.

deleted 2y ago

[deleted]

12_throw_away 2y ago

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

12_throw_away 2y ago
Also, I'm genuinely thrilled to see cross-pollination from pypy back to cpython, so am actually really glad they did it this way - as cpython's JIT becomes production-ready, maybe more bits of python will become be self-hosting?
boxed 2y ago
Also, jedi depends on parso. Parso does not yet support `match` (which is a big problem for me, as it means I need to switch AST library backing mutmut).
zahlman 2y ago
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.
- 0cf8612b2e1e 2y ago
  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’
wodenokoto 2y ago
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

o11c 2y ago

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

Macha 2y ago
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.
- o11c 2y ago
  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.

deleted 2y ago

[deleted]