Re: [Python-ideas] A better interactive prompt
On 10/25/2016 5:13 PM, Paul Moore wrote: 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. 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Thu, Oct 27, 2016 at 10:35:32AM +0100, Paul Moore 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. Ah, that makes sense. > 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. I think that making readline less aggressive (at least for Windows users) may be a reasonable feature request for 3.7. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On 27 October 2016 at 01:49, Steven D'Aprano wrote: >> (a bit like readline, >> but I dislike the way you can't switch off readline integration if >> it's installed)? > > 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? 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Wed, Oct 26, 2016 at 10:16 PM, Cody Piersall 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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Tue, Oct 25, 2016 at 10:13:54PM +0100, Paul Moore wrote: > I've seen a lot of syntax proposals recently that are based around > providing better ways of writing "one liner" styles of code. [...] > However, looking at them from the point of view of someone working at > the interactive prompt, they can seem much more attractive. 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 ;-) > So maybe it's > worth looking at the root issue, how to make the interactive prompt > easier to use[2]? 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 :-) > 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? 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/issue8 > Maybe > even, if IPython is available, allowing the user to configure Python > to use it by default as the interactive prompt I feel that is more something that people should configure their personal desktop or shell environment for, e.g. by setting up an alias. > (a bit like readline, > but I dislike the way you can't switch off readline integration if > it's installed)? 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. > 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. 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. > [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). Exactly. -- Steve
Re: [Python-ideas] A better interactive prompt
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.
> I often have elements like this in shell scripts:
>
> output=$(python < 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.
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
Re: [Python-ideas] A better interactive prompt
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!) >> >> > 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 > > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On 26/10/2016 20:24, Paul Moore wrote: On 26 October 2016 at 18:25, Nick Coghlan 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. 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'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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Wed, Oct 26, 2016 at 3:16 PM, Cody Piersall wrote: > On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore 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. > > 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: 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore 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.
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
#ifdef _WIN32
# include
# define isatty _isatty
# define fileno _fileno
#else
# include
#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");
}
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On 26 October 2016 at 22:40, Nikolaus Rath wrote:
> It also imposes a significant burden on scripting. I often have elements
> like this in shell scripts:
>
> output=$(python < 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.
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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Oct 26 2016, Paul Moore 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. > > 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. It also imposes a significant burden on scripting. I often have elements like this in shell scripts: output=$(python
Re: [Python-ideas] A better interactive prompt
On 26 October 2016 at 22:11, Todd 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Wed, Oct 26, 2016 at 3:24 PM, Paul Moore wrote: > On 26 October 2016 at 18:25, Nick Coghlan 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. > > 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: > > 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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On 26 October 2016 at 21:43, Nikolaus Rath wrote: >> 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. > > Uh, these are not advantages of plugging in a new REPL when > available. This describes the current situation. 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. > 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? > :-). 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Oct 26 2016, Paul Moore wrote: > On 26 October 2016 at 18:25, Nick Coghlan > 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. > > 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. 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.« ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On 26 October 2016 at 18:25, Nick Coghlan 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. 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. > 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. 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On 26 October 2016 at 09:15, Nathaniel Smith wrote: > 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. 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
On Tue, Oct 25, 2016 at 2:55 PM, Chris Barker wrote: > > >> 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? > > > +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. 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 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
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/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A better interactive prompt
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? +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.bar...@noaa.gov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] 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. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
