A better interactive prompt
I've seen a lot of syntax proposals recently that are based around providing better ways of writing "one liner" styles of code. Typically, the proposals seem to get into trouble because: 1. They duplicate things that can already be done, just not in a single expression/statement. 2. They are seen as over-terse, which is not generally seen as a good thing in Python. However, looking at them from the point of view of someone working at the interactive prompt, they can seem much more attractive. The natural unit of interaction at the command line is the single line. To the extent that (for example) fixing a mistake in a multi-line construct at the command line is a real pain. But these limitations are not inherent to Python - they are problems with the interactive prompt, which is fairly basic[1]. So maybe it's worth looking at the root issue, how to make the interactive prompt easier to use[2]? But that's something of a solved problem. IPython offers a rich interactive environment, for people who find the limitations of the standard interactive prompt frustrating. Would it be worth the standard Python documentation promoting IPython for that role? Maybe even, if IPython is available, allowing the user to configure Python to use it by default as the interactive prompt (a bit like readline, but I dislike the way you can't switch off readline integration if it's installed)? Ideally, if IPython was more readily available, fewer users would be frustrated with Python's existing multi-line constructs. And those that were, would have the option of looking into custom IPython magic commands, before being forced to request language changes. Thoughts? Paul [1] On the other hand, the interactive prompt is a huge part of what makes Python so great - these days, when I have to code in languages that don't have an interactive prompt, it drives me nuts. And even those that do, typically don't have one as good as Python's (in spite of the fact that this whole mail is about needing to improve the Python REPL). [2] My apologies to anyone whose proposal was *not* based around interactive use cases. I'm assuming motives here left, right and centre, so if what I'm saying isn't what you were intending, that's fine. Treat this as an unrelated proposal.
Would recommend bpython, it is lighter-weight and accessible to newbies, in the sense that a manual is not needed. It just starts helping out as you type. http://bpython-interpreter.org/
But that's something of a solved problem. IPython offers a rich
+1 iPython really makes it easier to do exploratory code -- I have my students install it day one of an intro to python class. However, maybe ironically, iPython is still a bit ugly for editing multi-line constructs -- maybe it will get better. The Jupyter (formally iPython) notebook is the way to go for that, but it has its other downsides... [2] My apologies to anyone whose proposal was *not* based around
interactive use cases.
folks DO like compact code, regardless of context :-) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Tue, Oct 25, 2016 at 2:55 PM, Chris Barker <chris.barker@noaa.gov> wrote:
I'm sure it could be improved more, but since the 5.0 release IPython has been *way* better at editing multi-line constructs than the built-in REPL is. For example, if I type: In [1]: def f(): ...: return 1 ...: In [2]: and then press up-arrow once, it gives me the complete function body back and lets me move around and edit it. Incidentally, PyPy's built-in REPL handles multi-line constructs like IPython does, rather than like how the CPython built-in REPL does. There are a lot of logistic issues that would need to be dealt with before CPython could consider making a third-party REPL the default or anything like it... it looks like IPython's dependency tree is all pure-Python, which makes it more viable, but it's still a lot of code and on a very different development cycle than CPython. bpython appears to depend on greenlet, which is a whole other issue... OTOH it seems a little quixotic to spend lots of resources improving the built-in REPL when there are much better ones with vibrant developer communities. -n -- Nathaniel J. Smith -- https://vorpus.org
On 26 October 2016 at 09:15, Nathaniel Smith <njs@pobox.com> wrote:
The built-in REPL serves two quite divergent use cases, and I think we're well past the point where we can't readily support both use cases with a single implementation: - a minimalist interactive environment, that is *always* present, even if parts of the interpreter (most notably the import system) aren't working or have been deliberately disabled - a day-to-day working environment for Python developers The prevalence of the latter use case then leads to it also being used as a tool for introducing new developers to Python. The problem is that of these two use cases, the current default REPL is really only *good* at the first one - for the latter, it's instead only "frequently good enough", since there are much better alternatives out there that can depend on the whole Python ecosystem rather than having to make the assumption that they should still basically work even if the import system isn't currently set up to bring in external modules. One possible path towards improving the situation might be to look at the PyPy REPL (which is presumably implemented in RPython) and see if that would be suitable for incorporation into CPython as a frozen module (perhaps with some modifications). That has the advantage of making the REPL much easier to iterate on (since you can use the non-frozen version for development), while still making it available at runtime as part of the core Python binary. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 26 October 2016 at 18:25, Nick Coghlan <ncoghlan@gmail.com> wrote:
Thinking a little further about this, I think the reason I don't use IPython more, is because my muscle memory types "python" (or more often, "py") when I want an interactive prompt. And I do that for the reason you mention - it's always there. So I think that it would be really useful to be able to plug in a new REPL, when it's available. This has a number of benefits: 1. We don't need to worry about incorporating any complex REPL code into Python. The default REPL can remain simple. 2. Users can choose their preferred REPL, core Python doesn't have to get involved in UI decisions. The downside, of course, is that the default behaviour is inconsistent - new users could attend a course where IPython was preinstalled, but then struggle when back at the office because no-one told them how to set it up.
I've never used the PyPy REPL, so I can't speak to its features. But this seems to me to simply be a matter of incremental improvement to the standard REPL, That's no bad thing, but as you pointed out at the start, we can't support both of our use cases with a single implementation, so this doesn't solve the fundamental problem - it merely alters the breakpoint at which people need to learn not to fire up the REPL, but rather to start up IPython, or bpython, or their environment of choice. And it doesn't do much for people who (like me) type "python" instinctively, and only realise they needed something better part way through their session. Paul
On Oct 26 2016, Paul Moore <p.f.moore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Uh, these are not advantages of plugging in a new REPL when available. This describes the current situation. At least in your email above you seem to be arguing that Python should change to better accomodate your muscle memory. I don't want to diminuish your importance, but doesn't that maybe go a little too far? :-). Best, -Niko -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 26 October 2016 at 21:43, Nikolaus Rath <Nikolaus@rath.org> wrote:
I'm confused. With regard to (1), the current situation is that there may be benefit to improving some aspects of the REPL. But we have no option if we want to do that, other than modifying the standard REPL. And for (2), sure users can choose the REPL they use (by running a different application such as IPython), but they can't change which is the *default* REPL (the one the "python" command provides). You can disagree as to how significant those benefits are, but they are not things we have right now.
You're misinterpreting me. I'm saying that people in general are used to getting an interactive prompt when they run Python. I'm suggesting that being able to configure a better REPL for that situation would be useful, because it allows people to gain the benefit of enhanced capabilities, while not having to learn (and remember to use) a new command. I'm also saying that making the REPL pluggable means that core Python doesn't have to get into the business of developing/maintaining a better REPL. Yes, I'd find the capability useful. Would it help my credibility if I proposed a change that made my life harder? :-) Paul
On Wed, Oct 26, 2016 at 3:24 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Isn't this what aliases are for? Just set "python" to be an alias for "ipython" for your interactive shell. Personally, my muscle memory is trained to always type "ipython3". I only type "python" or "python3" when I specifically want a vanilla shell (such as for trying things out without all my default imports, which I know could be done with profiles but that is even more typing). Having "python3" somehow changed to "ipython3" automatically would make things more difficult for me since I would need to do something more complicated to get back the vanilla shell when I need it.
On 26 October 2016 at 22:11, Todd <toddrjen@gmail.com> wrote:
Isn't this what aliases are for? Just set "python" to be an alias for "ipython" for your interactive shell.
I hadn't thought of that option. I might give it a try. Although I'm not sure how I'd set up a Powershell function (I'm on Windows) that would wrap the launcher (which selects the version of Python to use) and invoke IPython. I'll give it a go, though. Paul
On Oct 26 2016, Paul Moore <p.f.moore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
It also imposes a significant burden on scripting. I often have elements like this in shell scripts: output=$(python <<EOF import h5py with h5py.File('foo', 'r') as fh: print((fh['bla'] * fh['com']).sum()) EOF ) If this now starts up IPython, it'll be *significantly* slower. Yes, I could factor this out in a separate .py file, but it's much easier to understand when embedded directly into the relevant context. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 26 October 2016 at 22:40, Nikolaus Rath <Nikolaus@rath.org> wrote:
Good point. We could, of course, detect when stdin is non-interactive, but at that point the code is starting to get unreasonably complex, as well as having way too many special cases. So I agree, that probably kills the proposal. Paul
On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Isn't that check really just an isatty() check? Or is that not reliable enough for some reason? Here's some code that performs that check, and works on Linux and Windows: #include <stdio.h> #ifdef _WIN32 # include <io.h> # define isatty _isatty # define fileno _fileno #else # include <unistd.h> #endif int main( void ) { /* If stdin is a tty, you would launch the user's configured REPL*/ if(isatty(fileno(stdin))) printf("stdin has not been redirected to a file\n"); /* Otherwise, launch the default REPL (or maybe don't launch a REPL at all, * and just treat stdin as a file */ else printf("stdin has been redirected to a file\n"); }
On Wed, Oct 26, 2016 at 3:16 PM, Cody Piersall <cody.piersall@gmail.com> wrote:
It might or might not be an isatty() check (it's actually a bit more complicated, there's -i and various other things to take into account), but it hardly matters -- Python already has well-defined logic for deciding whether it should launch an interactive REPL or not. If we were going to do this, we'd keep that logic in place while swapping out the actual start_a_REPL() call with something else. There might be showstoppers here but I don't think this is one of them :-) -n -- Nathaniel J. Smith -- https://vorpus.org
On Wed, Oct 26, 2016 at 10:16 PM, Cody Piersall <cody.piersall@gmail.com> wrote:
Isn't that check really just an isatty() check? Or is that not reliable enough for some reason?
It's not reliable in Windows. There are no tty devices, so the C runtime's implementation of isatty() instead returns true for character devices, which includes the console as well as the NUL device and communication ports. For example: C:\>python -c "import sys; print(sys.stdin.isatty())" < nul True `python < nul` starts the REPL, but it immediately closes because there's nothing to read. On the other hand, reading from COM3 on my current system blocks, and the only way to exit the REPL is to kill the process, such as via Ctrl+Break: C:\>python < com3 Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^C The way to check for a console input or screen buffer is by calling GetConsoleMode on the handle.
On Wed, Oct 26, 2016 at 02:40:36PM -0700, Nikolaus Rath wrote:
It also imposes a significant burden on scripting.
"It" being a configurable REPL.
Surely this won't be a real problem in practice. Unless you give -i as a command line switch, calling Python as a script shouldn't need to run the REPL. But even if it did, if Python's REPL was configurable, there has to be a way to configure it. And presumably by default it would fall back to the standard vanilla REPL. So "python" in your shell script will probably refer to "the system Python, using the default REPL" rather than whatever personalised Python + REPL your own personal environment sets up for when you type "python" at the shell prompt. And if not, then something like this: output=$(python --use-std-repl <<EOF ... may be all you need. -- Steve
On 26/10/2016 20:24, Paul Moore wrote:
I'll just say that on Windows 10 I have ConEmu installed, and I edit the startup file to point me to umpteen different places where I want to work. Ipython is one of them. Of course it is extremely difficult to install. My understanding is that on Windows folk find it difficult to type:- pip install ipython What have I missed? -- Mark Lawrence
Mark, Windows folk do not type pip install ipython On windows it's much easier: 1) install pycharm (because it has UI for installing packages) 2) Go to settings > project interpreter 3) select the python interpeter you want to use 4) click the + button 5) search through the entire pypi listing for IPython 6) click install package (Off topic I know - but I couldn't resist!)
On Tue, Oct 25, 2016 at 10:13:54PM +0100, Paul Moore wrote:
I spend a lot of time working at the interactive prompt, and I don't agree that these proposals seem more attractive for that reason. [...]
But these limitations are not inherent to Python - they are problems with the interactive prompt, which is fairly basic[1].
It really isn't that basic. But you know that, as your footnote points out ;-)
I'm completely happy with moves to make the REPL better, but it won't make a lick of difference. Some people simply like one-liners, and won't be happy until they can write an entire application as a single, short one-liner. Look at the popularity of Perl. Or for that matter, APL. Some people are more concerned with minimizing the amount of vertical space a chunk of code users, or horizontal space, or keystrokes. Of course we *should* care about these things! We may disagree about the relative weight we give to these factors, not that they are important. There's always going to be tension between those who want to save just one more line and those who think oh no not another cryptic symbol to memorize. I think the Python community has managed to fit itself into a nice position in the "Goldilocks Zone" of syntax: not too much, not too little. But there's always going to be disagreements over precisely how much is too much, and a better REPL isn't going to stop that. There's space for lots of languages in the world, and I'm glad there is room for those who love Perl one-liners to write Perl. I just don't want them turning Python into a second-rate Perl :-)
IPython is no panacea. It's too rich, too powerful for many users. Not everybody wants to replace their regular shell (say, bash) with IPython. And some of us don't like IPython's [in] [out] prompts and all those unnecessary blank lines. We *should* promote third-party REPLs like IPython and BPython as alternatives for power users. http://bpython-interpreter.org/ But we shouldn't use that as an excuse to neglect the standard REPL, which is pretty good. For my uses, there's not a lot that I think is missing: Python's REPL on Linux with readline is pretty darn good. Perhaps the main feature that I miss is this: http://bugs.python.org/issue22228
I feel that is more something that people should configure their personal desktop or shell environment for, e.g. by setting up an alias.
This comment surprises me. To me, that's like saying "I dislike the way you can't switch off breathing" -- readline is almost indispensible. The REPL experience without line editing (apart from backspace) and history is *horrible*. Why would you want to switch it off? My hobby is collecting old Python versions, some of which are old enough that they don't support readline. (Or were never configured correctly for readline.) I don't use them often, but when I do, the experience is painful.
I don't think that the interactive prompt is what drives these requests. I think they are usually driven by differences in the weight people give to certain desirable characteristics of code. Some people have a higher tolerance towards terse special syntax; some people have a higher tolerance towards verbosity. Neither is completely wrong (although I feel that COBOL-like verbosity is probably less harmful than extremely terse languages like specialist code-golf languages). There will always be disagreements.
Exactly. -- Steve
On 27 October 2016 at 01:49, Steven D'Aprano <steve@pearwood.info> wrote:
The Windows default command line editing experience is a lot better (IMO) than the (non-readline) Unix default, and it's common throughout all interactive prompts (Python's REPL included). As a result, when readline is installed (pyreadline on Windows, which used to be needed for IPython) it disrupts the "normal" editing experience. It's possible that with a bit of configuration and practice I could get used to the readline experience, but then I get a different experience when in a venv where I don't have pyreadline installed. The idea that simply having a module called "readline" available, changes the REPL behaviour, with no way to configure that, seems incredibly hostile to me. Of course it's arguably pyreadline's fault for reusing a stdlib name, but nevertheless it's not something I agree with. Paul
On 10/25/2016 5:13 PM, Paul Moore wrote:
Try IDLE. The unit of interaction is the statement. One writes, edits, and submits entire statements. PREV recalls the previous statement as a whole and one edits the entire statement before resubmitting. For me, for Python, statements are the natural unit of interaction. -- Terry Jan Reedy
Would recommend bpython, it is lighter-weight and accessible to newbies, in the sense that a manual is not needed. It just starts helping out as you type. http://bpython-interpreter.org/
But that's something of a solved problem. IPython offers a rich
+1 iPython really makes it easier to do exploratory code -- I have my students install it day one of an intro to python class. However, maybe ironically, iPython is still a bit ugly for editing multi-line constructs -- maybe it will get better. The Jupyter (formally iPython) notebook is the way to go for that, but it has its other downsides... [2] My apologies to anyone whose proposal was *not* based around
interactive use cases.
folks DO like compact code, regardless of context :-) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Tue, Oct 25, 2016 at 2:55 PM, Chris Barker <chris.barker@noaa.gov> wrote:
I'm sure it could be improved more, but since the 5.0 release IPython has been *way* better at editing multi-line constructs than the built-in REPL is. For example, if I type: In [1]: def f(): ...: return 1 ...: In [2]: and then press up-arrow once, it gives me the complete function body back and lets me move around and edit it. Incidentally, PyPy's built-in REPL handles multi-line constructs like IPython does, rather than like how the CPython built-in REPL does. There are a lot of logistic issues that would need to be dealt with before CPython could consider making a third-party REPL the default or anything like it... it looks like IPython's dependency tree is all pure-Python, which makes it more viable, but it's still a lot of code and on a very different development cycle than CPython. bpython appears to depend on greenlet, which is a whole other issue... OTOH it seems a little quixotic to spend lots of resources improving the built-in REPL when there are much better ones with vibrant developer communities. -n -- Nathaniel J. Smith -- https://vorpus.org
On 26 October 2016 at 09:15, Nathaniel Smith <njs@pobox.com> wrote:
The built-in REPL serves two quite divergent use cases, and I think we're well past the point where we can't readily support both use cases with a single implementation: - a minimalist interactive environment, that is *always* present, even if parts of the interpreter (most notably the import system) aren't working or have been deliberately disabled - a day-to-day working environment for Python developers The prevalence of the latter use case then leads to it also being used as a tool for introducing new developers to Python. The problem is that of these two use cases, the current default REPL is really only *good* at the first one - for the latter, it's instead only "frequently good enough", since there are much better alternatives out there that can depend on the whole Python ecosystem rather than having to make the assumption that they should still basically work even if the import system isn't currently set up to bring in external modules. One possible path towards improving the situation might be to look at the PyPy REPL (which is presumably implemented in RPython) and see if that would be suitable for incorporation into CPython as a frozen module (perhaps with some modifications). That has the advantage of making the REPL much easier to iterate on (since you can use the non-frozen version for development), while still making it available at runtime as part of the core Python binary. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 26 October 2016 at 18:25, Nick Coghlan <ncoghlan@gmail.com> wrote:
Thinking a little further about this, I think the reason I don't use IPython more, is because my muscle memory types "python" (or more often, "py") when I want an interactive prompt. And I do that for the reason you mention - it's always there. So I think that it would be really useful to be able to plug in a new REPL, when it's available. This has a number of benefits: 1. We don't need to worry about incorporating any complex REPL code into Python. The default REPL can remain simple. 2. Users can choose their preferred REPL, core Python doesn't have to get involved in UI decisions. The downside, of course, is that the default behaviour is inconsistent - new users could attend a course where IPython was preinstalled, but then struggle when back at the office because no-one told them how to set it up.
I've never used the PyPy REPL, so I can't speak to its features. But this seems to me to simply be a matter of incremental improvement to the standard REPL, That's no bad thing, but as you pointed out at the start, we can't support both of our use cases with a single implementation, so this doesn't solve the fundamental problem - it merely alters the breakpoint at which people need to learn not to fire up the REPL, but rather to start up IPython, or bpython, or their environment of choice. And it doesn't do much for people who (like me) type "python" instinctively, and only realise they needed something better part way through their session. Paul
On Oct 26 2016, Paul Moore <p.f.moore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Uh, these are not advantages of plugging in a new REPL when available. This describes the current situation. At least in your email above you seem to be arguing that Python should change to better accomodate your muscle memory. I don't want to diminuish your importance, but doesn't that maybe go a little too far? :-). Best, -Niko -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 26 October 2016 at 21:43, Nikolaus Rath <Nikolaus@rath.org> wrote:
I'm confused. With regard to (1), the current situation is that there may be benefit to improving some aspects of the REPL. But we have no option if we want to do that, other than modifying the standard REPL. And for (2), sure users can choose the REPL they use (by running a different application such as IPython), but they can't change which is the *default* REPL (the one the "python" command provides). You can disagree as to how significant those benefits are, but they are not things we have right now.
You're misinterpreting me. I'm saying that people in general are used to getting an interactive prompt when they run Python. I'm suggesting that being able to configure a better REPL for that situation would be useful, because it allows people to gain the benefit of enhanced capabilities, while not having to learn (and remember to use) a new command. I'm also saying that making the REPL pluggable means that core Python doesn't have to get into the business of developing/maintaining a better REPL. Yes, I'd find the capability useful. Would it help my credibility if I proposed a change that made my life harder? :-) Paul
On Wed, Oct 26, 2016 at 3:24 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Isn't this what aliases are for? Just set "python" to be an alias for "ipython" for your interactive shell. Personally, my muscle memory is trained to always type "ipython3". I only type "python" or "python3" when I specifically want a vanilla shell (such as for trying things out without all my default imports, which I know could be done with profiles but that is even more typing). Having "python3" somehow changed to "ipython3" automatically would make things more difficult for me since I would need to do something more complicated to get back the vanilla shell when I need it.
On 26 October 2016 at 22:11, Todd <toddrjen@gmail.com> wrote:
Isn't this what aliases are for? Just set "python" to be an alias for "ipython" for your interactive shell.
I hadn't thought of that option. I might give it a try. Although I'm not sure how I'd set up a Powershell function (I'm on Windows) that would wrap the launcher (which selects the version of Python to use) and invoke IPython. I'll give it a go, though. Paul
On Oct 26 2016, Paul Moore <p.f.moore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
It also imposes a significant burden on scripting. I often have elements like this in shell scripts: output=$(python <<EOF import h5py with h5py.File('foo', 'r') as fh: print((fh['bla'] * fh['com']).sum()) EOF ) If this now starts up IPython, it'll be *significantly* slower. Yes, I could factor this out in a separate .py file, but it's much easier to understand when embedded directly into the relevant context. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 26 October 2016 at 22:40, Nikolaus Rath <Nikolaus@rath.org> wrote:
Good point. We could, of course, detect when stdin is non-interactive, but at that point the code is starting to get unreasonably complex, as well as having way too many special cases. So I agree, that probably kills the proposal. Paul
On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Isn't that check really just an isatty() check? Or is that not reliable enough for some reason? Here's some code that performs that check, and works on Linux and Windows: #include <stdio.h> #ifdef _WIN32 # include <io.h> # define isatty _isatty # define fileno _fileno #else # include <unistd.h> #endif int main( void ) { /* If stdin is a tty, you would launch the user's configured REPL*/ if(isatty(fileno(stdin))) printf("stdin has not been redirected to a file\n"); /* Otherwise, launch the default REPL (or maybe don't launch a REPL at all, * and just treat stdin as a file */ else printf("stdin has been redirected to a file\n"); }
On Wed, Oct 26, 2016 at 3:16 PM, Cody Piersall <cody.piersall@gmail.com> wrote:
It might or might not be an isatty() check (it's actually a bit more complicated, there's -i and various other things to take into account), but it hardly matters -- Python already has well-defined logic for deciding whether it should launch an interactive REPL or not. If we were going to do this, we'd keep that logic in place while swapping out the actual start_a_REPL() call with something else. There might be showstoppers here but I don't think this is one of them :-) -n -- Nathaniel J. Smith -- https://vorpus.org
On Wed, Oct 26, 2016 at 10:16 PM, Cody Piersall <cody.piersall@gmail.com> wrote:
Isn't that check really just an isatty() check? Or is that not reliable enough for some reason?
It's not reliable in Windows. There are no tty devices, so the C runtime's implementation of isatty() instead returns true for character devices, which includes the console as well as the NUL device and communication ports. For example: C:\>python -c "import sys; print(sys.stdin.isatty())" < nul True `python < nul` starts the REPL, but it immediately closes because there's nothing to read. On the other hand, reading from COM3 on my current system blocks, and the only way to exit the REPL is to kill the process, such as via Ctrl+Break: C:\>python < com3 Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^C The way to check for a console input or screen buffer is by calling GetConsoleMode on the handle.
On Wed, Oct 26, 2016 at 02:40:36PM -0700, Nikolaus Rath wrote:
It also imposes a significant burden on scripting.
"It" being a configurable REPL.
Surely this won't be a real problem in practice. Unless you give -i as a command line switch, calling Python as a script shouldn't need to run the REPL. But even if it did, if Python's REPL was configurable, there has to be a way to configure it. And presumably by default it would fall back to the standard vanilla REPL. So "python" in your shell script will probably refer to "the system Python, using the default REPL" rather than whatever personalised Python + REPL your own personal environment sets up for when you type "python" at the shell prompt. And if not, then something like this: output=$(python --use-std-repl <<EOF ... may be all you need. -- Steve
On 26/10/2016 20:24, Paul Moore wrote:
I'll just say that on Windows 10 I have ConEmu installed, and I edit the startup file to point me to umpteen different places where I want to work. Ipython is one of them. Of course it is extremely difficult to install. My understanding is that on Windows folk find it difficult to type:- pip install ipython What have I missed? -- Mark Lawrence
Mark, Windows folk do not type pip install ipython On windows it's much easier: 1) install pycharm (because it has UI for installing packages) 2) Go to settings > project interpreter 3) select the python interpeter you want to use 4) click the + button 5) search through the entire pypi listing for IPython 6) click install package (Off topic I know - but I couldn't resist!)
On Tue, Oct 25, 2016 at 10:13:54PM +0100, Paul Moore wrote:
I spend a lot of time working at the interactive prompt, and I don't agree that these proposals seem more attractive for that reason. [...]
But these limitations are not inherent to Python - they are problems with the interactive prompt, which is fairly basic[1].
It really isn't that basic. But you know that, as your footnote points out ;-)
I'm completely happy with moves to make the REPL better, but it won't make a lick of difference. Some people simply like one-liners, and won't be happy until they can write an entire application as a single, short one-liner. Look at the popularity of Perl. Or for that matter, APL. Some people are more concerned with minimizing the amount of vertical space a chunk of code users, or horizontal space, or keystrokes. Of course we *should* care about these things! We may disagree about the relative weight we give to these factors, not that they are important. There's always going to be tension between those who want to save just one more line and those who think oh no not another cryptic symbol to memorize. I think the Python community has managed to fit itself into a nice position in the "Goldilocks Zone" of syntax: not too much, not too little. But there's always going to be disagreements over precisely how much is too much, and a better REPL isn't going to stop that. There's space for lots of languages in the world, and I'm glad there is room for those who love Perl one-liners to write Perl. I just don't want them turning Python into a second-rate Perl :-)
IPython is no panacea. It's too rich, too powerful for many users. Not everybody wants to replace their regular shell (say, bash) with IPython. And some of us don't like IPython's [in] [out] prompts and all those unnecessary blank lines. We *should* promote third-party REPLs like IPython and BPython as alternatives for power users. http://bpython-interpreter.org/ But we shouldn't use that as an excuse to neglect the standard REPL, which is pretty good. For my uses, there's not a lot that I think is missing: Python's REPL on Linux with readline is pretty darn good. Perhaps the main feature that I miss is this: http://bugs.python.org/issue22228
I feel that is more something that people should configure their personal desktop or shell environment for, e.g. by setting up an alias.
This comment surprises me. To me, that's like saying "I dislike the way you can't switch off breathing" -- readline is almost indispensible. The REPL experience without line editing (apart from backspace) and history is *horrible*. Why would you want to switch it off? My hobby is collecting old Python versions, some of which are old enough that they don't support readline. (Or were never configured correctly for readline.) I don't use them often, but when I do, the experience is painful.
I don't think that the interactive prompt is what drives these requests. I think they are usually driven by differences in the weight people give to certain desirable characteristics of code. Some people have a higher tolerance towards terse special syntax; some people have a higher tolerance towards verbosity. Neither is completely wrong (although I feel that COBOL-like verbosity is probably less harmful than extremely terse languages like specialist code-golf languages). There will always be disagreements.
Exactly. -- Steve
On 27 October 2016 at 01:49, Steven D'Aprano <steve@pearwood.info> wrote:
The Windows default command line editing experience is a lot better (IMO) than the (non-readline) Unix default, and it's common throughout all interactive prompts (Python's REPL included). As a result, when readline is installed (pyreadline on Windows, which used to be needed for IPython) it disrupts the "normal" editing experience. It's possible that with a bit of configuration and practice I could get used to the readline experience, but then I get a different experience when in a venv where I don't have pyreadline installed. The idea that simply having a module called "readline" available, changes the REPL behaviour, with no way to configure that, seems incredibly hostile to me. Of course it's arguably pyreadline's fault for reusing a stdlib name, but nevertheless it's not something I agree with. Paul
On 10/25/2016 5:13 PM, Paul Moore wrote:
Try IDLE. The unit of interaction is the statement. One writes, edits, and submits entire statements. PREV recalls the previous statement as a whole and one edits the entire statement before resubmitting. For me, for Python, statements are the natural unit of interaction. -- Terry Jan Reedy
participants (13)
-
Chris Barker -
Cody Piersall -
eryk sun -
Mark Lawrence -
Mike Miller -
Nathaniel Smith -
Nick Coghlan -
Nikolaus Rath -
Paul Moore -
Steven D'Aprano -
Terry Reedy -
Tim Mitchell -
Todd