From kbk at shore.net Wed Dec 24 06:29:22 2014 From: kbk at shore.net (Kurt B. Kaiser) Date: Wed, 24 Dec 2014 00:29:22 -0500 Subject: [Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?] In-Reply-To: References: Message-ID: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> On Tue, Dec 23, 2014, at 10:30 PM, Al Sweigart wrote: > Hello, I'm Al Sweigart. I've joined the idle-dev list, but I can't > seem to post to the list. I made an announcement about the "IDLE > Reimagined" project, but I haven't received it from the list nor has > it appeared in the archive on the web. Are my posts being held in > moderation? Is there someone else I should talk to about the idle- > dev list? > > Thanks for your time, Hi Al, I think that the reason your second message didn't make it was because it is chock full of html. You may not be aware that posting to the python lists should be done using plain text. At least the second message didn't reference your ad-ridden wikia. Many people have designed Python IDEs. It seems that Scheme coders write their own Scheme, and Python coders write their own IDEs. Lots of editors: https://wiki.python.org/moin/PythonEditors Lots of IDEs: https://wiki.python.org/moin/IntegratedDevelopmentEnvironments In particular, there are many professional, complex IDEs. I remember sitting through a PyCharm presentation at PyCon. The first question was, essentially, "How do you turn all that stuff off?" IDLE is perfectly usable for "professional" development. I use it with emacs for the C parts and command line for project and version control. It does what I want. (Up to the point where I ran out of time to work on it.) It has its own niche, "non-complex, cross- platform IDEs". It's very important that a cross platform IDE be available out of the box when Python is installed. The interactive interpreter in a shell window doesn't cut it, especially on Windows. I read through your 2011 blog entry. It has a number of good ideas and points out things that need fixing. Some have been. Some of your points are just IDLE idiosyncrasies, like the End key jumping between the ends of the line. I found that useful for selecting lines and changing indentation; you might come to like it. (I see that isn't working in 2.7.3, maybe someone "fixed" it...too bad.) Idiosyncrasy: The Python shell uses readline - the up arrow will move history to the command line. In the IDLE shell, GvR didn't copy that, but the up arrow key moves to the previous lines. If you hit most keys, you get a beep, as you noticed. But if you hit enter, the *whole expression* is copied to the command line, and it can be edited. That's pretty cool. It is explained in the IDLE help, in the **TIPS**/Python Shell section. Once shown, a kid will pick that up in a moment, with a big smile. Saves a lot of typing when frobbing around. I'm entirely in agreement that IDLE should be an IDE for beginners. If you want to re-imagine a beginner's cross-platform Python IDE, go for it. But choose your own name if you are going to really tear it up, please. It's more important to fix the IDLE bugs and make it really solid for beginners on all platforms, IMO. And avoid creeping features. Guido had good reasons for his choices, I think. There was a long thread on python-dev awhile back, here's one post: https://mail.python.org/pipermail/python-dev/2013-March/124842.html -- KBK From tjreedy at udel.edu Wed Dec 24 07:05:23 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 24 Dec 2014 01:05:23 -0500 Subject: [Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?] In-Reply-To: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> References: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> Message-ID: On 12/24/2014 12:29 AM, Kurt B. Kaiser wrote: > I read through your 2011 blog entry. It has a number of good ideas and > points out things that need fixing. Some have been. The blog is http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/ http://bugs.python.org/issue13504 is a meta-issue for specific issues related to the blog list. Last October I made a updated and detailed list of points made in the blog and comments and corresponding tracker issues. I reported some of the changes back on the blog in comments. -- Terry Jan Reedy From al at inventwithpython.com Wed Dec 24 22:55:29 2014 From: al at inventwithpython.com (Al Sweigart) Date: Wed, 24 Dec 2014 13:55:29 -0800 Subject: [Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?] In-Reply-To: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> References: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> Message-ID: On Tue, Dec 23, 2014 at 9:29 PM, Kurt B. Kaiser wrote: > > > On Tue, Dec 23, 2014, at 10:30 PM, Al Sweigart wrote: >> Hello, I'm Al Sweigart. I've joined the idle-dev list, but I can't >> seem to post to the list. I made an announcement about the "IDLE >> Reimagined" project, but I haven't received it from the list nor has >> it appeared in the archive on the web. Are my posts being held in >> moderation? Is there someone else I should talk to about the idle- >> dev list? >> >> Thanks for your time, > > Hi Al, > > I think that the reason your second message didn't make it was because > it is chock full of html. You may not be aware that posting to the > python lists should be done using plain text. > Sorry about that, I've used a gmail-handled account to post to Pipermail lists before with the default settings and it didn't have an html/plaintext problem. I'll make sure my gmail messages to the list are explicitly set to plaintext in the future. > At least the second message didn't reference your ad-ridden wikia. > > Also, I apologize for the wikia link. I run ad-block on Chrome and Firefox, and didn't realize wikia had obnoxious ads until someone else pointed it out to me. I've since moved it to github's wiki. > Many people have designed Python IDEs. It seems that Scheme coders > write their own Scheme, and Python coders write their own IDEs. > > Lots of editors: > > https://wiki.python.org/moin/PythonEditors > > Lots of IDEs: > > https://wiki.python.org/moin/IntegratedDevelopmentEnvironments > > I think the "reimagined" in IDLE Reimagined might be giving the wrong idea. The changes I'd like to see wouldn't be a brand new from-scratch application, but using tkinter and the IDLE code base. (I know how we like to write code more than to modify it, and how the "rebuild it from scratch" often replaces the old set of bugs with a new set of bugs.) The redesign that I'd like to see would be to make design tradeoffs in favor of new programmers rather than regular developers. > In particular, there are many professional, complex IDEs. I remember > sitting through a PyCharm presentation at PyCon. The first question > was, essentially, "How do you turn all that stuff off?" > I completely agree with you. I don't want IDLE to be littered with features the way Eclipse or Gimp is. > IDLE is perfectly usable for "professional" development. I use it with > emacs for the C parts and command line for project and version control. > > It does what I want. (Up to the point where I ran out of time to work on > it.) It has its own niche, "non-complex, cross- platform IDEs". > > It's very important that a cross platform IDE be available out of the > box when Python is installed. The interactive interpreter in a shell > window doesn't cut it, especially on Windows. > I also see the fact that Python comes with a cross platform IDE as critical for the success of Python. I've always thought of the success of PHP was due to how easy it was to install. Lowering the barrier to entry is why I'd like to make changes to IDLE (tabs, single window instead of separate editor/interactive shell, i18n, etc.) > I read through your 2011 blog entry. It has a number of good ideas and > points out things that need fixing. Some have been. Some of your points > are just IDLE idiosyncrasies, like the End key jumping between the ends > of the line. I found that useful for selecting lines and changing > indentation; you might come to like it. (I see that isn't working in > 2.7.3, maybe someone "fixed" it...too bad.) > Reading back over the blog post, I'm not sure I know the particular End key issue you're talking about. (There's one about the Home key moving to the start of the >>> prompt instead the start of the line.) But I can see how a lot of design choices can have multiple opinions; I'm writing up the IDLE Reimagined design as a starting point for conversation, not as a conclusion. Everything about IR is up for negotiation. > Idiosyncrasy: The Python shell uses readline - the up arrow will move > history to the command line. In the IDLE shell, GvR didn't copy that, > but the up arrow key moves to the previous lines. If you hit most keys, > you get a beep, as you noticed. But if you hit enter, the *whole > expression* is copied to the command line, and it can be edited. That's > pretty cool. It is explained in the IDLE help, in the **TIPS**/Python > Shell section. Once shown, a kid will pick that up in a moment, with a > big smile. Saves a lot of typing when frobbing around. > I stumbled on this feature by accident. Like most users, I didn't read the help file. (Heh.) > I'm entirely in agreement that IDLE should be an IDE for beginners. > > If you want to re-imagine a beginner's cross-platform Python IDE, go for > it. But choose your own name if you are going to really tear it up, > please. > It's more important to fix the IDLE bugs and make it really solid for > beginners on all platforms, IMO. And avoid creeping features. > Feature-creep is something I definitely want to avoid. I've added a list of features that IR would explicitly *not* have, as way to set expectations of scope: https://github.com/asweigart/idle-reimagined/wiki/Why-Use-the-Existing-IDLE-Codebase%3F The major new features in the IR design would be the simplified real-time lint and post-to-pastebin feature. They're a lot of work, but I think they'll provide a huge payoff as well. But yeah, fixing bugs should take priority over implementing major features (which themselves will have new bugs). Currently I'm doing some design sketches, but mostly reading through the IDLE code base, reading through the idle-dev archive, and poking around on the Python issue tracker. Big, fancy features come after the simple improvements. > Guido had good reasons for his choices, I think. > > There was a long thread on python-dev awhile back, here's one post: > > https://mail.python.org/pipermail/python-dev/2013-March/124842.html > I read through the thread. Whether or not IDLE development is spun off into a separate project (I don't know enough about IDLE's development yet), I agree with GvR that IDLE should stay in the distribution. I don't mean to step on toes, and I understand how overly-idealistic it looks for an outsider to come in and express several ideas for changes at once. (And, again, none of the suggestions I make are intended to be deeply staked into the ground.) But I see a lot of potential for IDLE coming from a UI design and Python educator background as far as lowering the barrier to entry for new users. It'll probably be about mid-January before I broach this topic again. I was just poking to see if there was interest on the idle-dev list for people who wanted to take a look at the initial ideas. In the meantime, I'll be familiarizing myself with the IDLE code base and the issue tracker more. > -- > KBK > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev From sarah.kuchinsky at gmail.com Fri Dec 26 23:39:53 2014 From: sarah.kuchinsky at gmail.com (Sarah) Date: Fri, 26 Dec 2014 14:39:53 -0800 Subject: [Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?] In-Reply-To: References: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> Message-ID: <8C12D274-EF07-4830-8FAE-40DFE2B0ED36@gmail.com> I highly recommend checking out Roger Serwy's IdleX. For a while, as I understand it, enhancements weren't accepted for Idle. Roger added a bunch of them, but since they weren't being applied, he forked everything, in order to make something that was souped up. It's nice. Someone correct me if I'm wrong? > On Dec 24, 2014, at 1:55 PM, Al Sweigart wrote: > >> On Tue, Dec 23, 2014 at 9:29 PM, Kurt B. Kaiser wrote: >> >> >>> On Tue, Dec 23, 2014, at 10:30 PM, Al Sweigart wrote: >>> Hello, I'm Al Sweigart. I've joined the idle-dev list, but I can't >>> seem to post to the list. I made an announcement about the "IDLE >>> Reimagined" project, but I haven't received it from the list nor has >>> it appeared in the archive on the web. Are my posts being held in >>> moderation? Is there someone else I should talk to about the idle- >>> dev list? >>> >>> Thanks for your time, >> >> Hi Al, >> >> I think that the reason your second message didn't make it was because >> it is chock full of html. You may not be aware that posting to the >> python lists should be done using plain text. > > Sorry about that, I've used a gmail-handled account to post to > Pipermail lists before with the default settings and it didn't have an > html/plaintext problem. I'll make sure my gmail messages to the list > are explicitly set to plaintext in the future. > >> At least the second message didn't reference your ad-ridden wikia. > > Also, I apologize for the wikia link. I run ad-block on Chrome and > Firefox, and didn't realize wikia had obnoxious ads until someone else > pointed it out to me. I've since moved it to github's wiki. > >> Many people have designed Python IDEs. It seems that Scheme coders >> write their own Scheme, and Python coders write their own IDEs. >> >> Lots of editors: >> >> https://wiki.python.org/moin/PythonEditors >> >> Lots of IDEs: >> >> https://wiki.python.org/moin/IntegratedDevelopmentEnvironments > > I think the "reimagined" in IDLE Reimagined might be giving the wrong > idea. The changes I'd like to see wouldn't be a brand new from-scratch > application, but using tkinter and the IDLE code base. (I know how we > like to write code more than to modify it, and how the "rebuild it > from scratch" often replaces the old set of bugs with a new set of > bugs.) The redesign that I'd like to see would be to make design > tradeoffs in favor of new programmers rather than regular developers. > >> In particular, there are many professional, complex IDEs. I remember >> sitting through a PyCharm presentation at PyCon. The first question >> was, essentially, "How do you turn all that stuff off?" > > I completely agree with you. I don't want IDLE to be littered with > features the way Eclipse or Gimp is. > >> IDLE is perfectly usable for "professional" development. I use it with >> emacs for the C parts and command line for project and version control. >> >> It does what I want. (Up to the point where I ran out of time to work on >> it.) It has its own niche, "non-complex, cross- platform IDEs". >> >> It's very important that a cross platform IDE be available out of the >> box when Python is installed. The interactive interpreter in a shell >> window doesn't cut it, especially on Windows. > > I also see the fact that Python comes with a cross platform IDE as > critical for the success of Python. I've always thought of the success > of PHP was due to how easy it was to install. Lowering the barrier to > entry is why I'd like to make changes to IDLE (tabs, single window > instead of separate editor/interactive shell, i18n, etc.) > >> I read through your 2011 blog entry. It has a number of good ideas and >> points out things that need fixing. Some have been. Some of your points >> are just IDLE idiosyncrasies, like the End key jumping between the ends >> of the line. I found that useful for selecting lines and changing >> indentation; you might come to like it. (I see that isn't working in >> 2.7.3, maybe someone "fixed" it...too bad.) > > Reading back over the blog post, I'm not sure I know the particular > End key issue you're talking about. (There's one about the Home key > moving to the start of the >>> prompt instead the start of the line.) > But I can see how a lot of design choices can have multiple opinions; > I'm writing up the IDLE Reimagined design as a starting point for > conversation, not as a conclusion. Everything about IR is up for > negotiation. > >> Idiosyncrasy: The Python shell uses readline - the up arrow will move >> history to the command line. In the IDLE shell, GvR didn't copy that, >> but the up arrow key moves to the previous lines. If you hit most keys, >> you get a beep, as you noticed. But if you hit enter, the *whole >> expression* is copied to the command line, and it can be edited. That's >> pretty cool. It is explained in the IDLE help, in the **TIPS**/Python >> Shell section. Once shown, a kid will pick that up in a moment, with a >> big smile. Saves a lot of typing when frobbing around. > > I stumbled on this feature by accident. Like most users, I didn't read > the help file. (Heh.) > >> I'm entirely in agreement that IDLE should be an IDE for beginners. >> >> If you want to re-imagine a beginner's cross-platform Python IDE, go for >> it. But choose your own name if you are going to really tear it up, >> please. >> It's more important to fix the IDLE bugs and make it really solid for >> beginners on all platforms, IMO. And avoid creeping features. > > Feature-creep is something I definitely want to avoid. I've added a > list of features that IR would explicitly *not* have, as way to set > expectations of scope: > https://github.com/asweigart/idle-reimagined/wiki/Why-Use-the-Existing-IDLE-Codebase%3F > > The major new features in the IR design would be the simplified > real-time lint and post-to-pastebin feature. They're a lot of work, > but I think they'll provide a huge payoff as well. But yeah, fixing > bugs should take priority over implementing major features (which > themselves will have new bugs). Currently I'm doing some design > sketches, but mostly reading through the IDLE code base, reading > through the idle-dev archive, and poking around on the Python issue > tracker. > > Big, fancy features come after the simple improvements. > >> Guido had good reasons for his choices, I think. >> >> There was a long thread on python-dev awhile back, here's one post: >> >> https://mail.python.org/pipermail/python-dev/2013-March/124842.html > > I read through the thread. Whether or not IDLE development is spun off > into a separate project (I don't know enough about IDLE's development > yet), I agree with GvR that IDLE should stay in the distribution. > > I don't mean to step on toes, and I understand how overly-idealistic > it looks for an outsider to come in and express several ideas for > changes at once. (And, again, none of the suggestions I make are > intended to be deeply staked into the ground.) But I see a lot of > potential for IDLE coming from a UI design and Python educator > background as far as lowering the barrier to entry for new users. > > It'll probably be about mid-January before I broach this topic again. > I was just poking to see if there was interest on the idle-dev list > for people who wanted to take a look at the initial ideas. In the > meantime, I'll be familiarizing myself with the IDLE code base and the > issue tracker more. > >> -- >> KBK >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> https://mail.python.org/mailman/listinfo/idle-dev > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev From ether.joe at gmail.com Sat Dec 27 01:11:14 2014 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Fri, 26 Dec 2014 16:11:14 -0800 Subject: [Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?] In-Reply-To: <8C12D274-EF07-4830-8FAE-40DFE2B0ED36@gmail.com> References: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> <8C12D274-EF07-4830-8FAE-40DFE2B0ED36@gmail.com> Message-ID: Hey Al - love your books ! I read your blog post a while back and I agree with most if not all of it. As I recall, a lot of these fixes are actually code complete but just need verification and inclusion in the next Python version. For example, making the shell more terminal-like, eg. having an out-of-focus keystroke take you to the >>> prompt and begin typing -- this fix is actually done for a while but just hasn't been included. I actually applied the patch manually myself and it's working well. Anyhow -- +1 for idle improvements -- I love this little editor ! On Fri, Dec 26, 2014 at 2:39 PM, Sarah wrote: > I highly recommend checking out Roger Serwy's IdleX. > > For a while, as I understand it, enhancements weren't accepted for Idle. Roger added a bunch of them, but since they weren't being applied, he forked everything, in order to make something that was souped up. > > It's nice. > > Someone correct me if I'm wrong? > >> On Dec 24, 2014, at 1:55 PM, Al Sweigart wrote: >> >>> On Tue, Dec 23, 2014 at 9:29 PM, Kurt B. Kaiser wrote: >>> >>> >>>> On Tue, Dec 23, 2014, at 10:30 PM, Al Sweigart wrote: >>>> Hello, I'm Al Sweigart. I've joined the idle-dev list, but I can't >>>> seem to post to the list. I made an announcement about the "IDLE >>>> Reimagined" project, but I haven't received it from the list nor has >>>> it appeared in the archive on the web. Are my posts being held in >>>> moderation? Is there someone else I should talk to about the idle- >>>> dev list? >>>> >>>> Thanks for your time, >>> >>> Hi Al, >>> >>> I think that the reason your second message didn't make it was because >>> it is chock full of html. You may not be aware that posting to the >>> python lists should be done using plain text. >> >> Sorry about that, I've used a gmail-handled account to post to >> Pipermail lists before with the default settings and it didn't have an >> html/plaintext problem. I'll make sure my gmail messages to the list >> are explicitly set to plaintext in the future. >> >>> At least the second message didn't reference your ad-ridden wikia. >> >> Also, I apologize for the wikia link. I run ad-block on Chrome and >> Firefox, and didn't realize wikia had obnoxious ads until someone else >> pointed it out to me. I've since moved it to github's wiki. >> >>> Many people have designed Python IDEs. It seems that Scheme coders >>> write their own Scheme, and Python coders write their own IDEs. >>> >>> Lots of editors: >>> >>> https://wiki.python.org/moin/PythonEditors >>> >>> Lots of IDEs: >>> >>> https://wiki.python.org/moin/IntegratedDevelopmentEnvironments >> >> I think the "reimagined" in IDLE Reimagined might be giving the wrong >> idea. The changes I'd like to see wouldn't be a brand new from-scratch >> application, but using tkinter and the IDLE code base. (I know how we >> like to write code more than to modify it, and how the "rebuild it >> from scratch" often replaces the old set of bugs with a new set of >> bugs.) The redesign that I'd like to see would be to make design >> tradeoffs in favor of new programmers rather than regular developers. >> >>> In particular, there are many professional, complex IDEs. I remember >>> sitting through a PyCharm presentation at PyCon. The first question >>> was, essentially, "How do you turn all that stuff off?" >> >> I completely agree with you. I don't want IDLE to be littered with >> features the way Eclipse or Gimp is. >> >>> IDLE is perfectly usable for "professional" development. I use it with >>> emacs for the C parts and command line for project and version control. >>> >>> It does what I want. (Up to the point where I ran out of time to work on >>> it.) It has its own niche, "non-complex, cross- platform IDEs". >>> >>> It's very important that a cross platform IDE be available out of the >>> box when Python is installed. The interactive interpreter in a shell >>> window doesn't cut it, especially on Windows. >> >> I also see the fact that Python comes with a cross platform IDE as >> critical for the success of Python. I've always thought of the success >> of PHP was due to how easy it was to install. Lowering the barrier to >> entry is why I'd like to make changes to IDLE (tabs, single window >> instead of separate editor/interactive shell, i18n, etc.) >> >>> I read through your 2011 blog entry. It has a number of good ideas and >>> points out things that need fixing. Some have been. Some of your points >>> are just IDLE idiosyncrasies, like the End key jumping between the ends >>> of the line. I found that useful for selecting lines and changing >>> indentation; you might come to like it. (I see that isn't working in >>> 2.7.3, maybe someone "fixed" it...too bad.) >> >> Reading back over the blog post, I'm not sure I know the particular >> End key issue you're talking about. (There's one about the Home key >> moving to the start of the >>> prompt instead the start of the line.) >> But I can see how a lot of design choices can have multiple opinions; >> I'm writing up the IDLE Reimagined design as a starting point for >> conversation, not as a conclusion. Everything about IR is up for >> negotiation. >> >>> Idiosyncrasy: The Python shell uses readline - the up arrow will move >>> history to the command line. In the IDLE shell, GvR didn't copy that, >>> but the up arrow key moves to the previous lines. If you hit most keys, >>> you get a beep, as you noticed. But if you hit enter, the *whole >>> expression* is copied to the command line, and it can be edited. That's >>> pretty cool. It is explained in the IDLE help, in the **TIPS**/Python >>> Shell section. Once shown, a kid will pick that up in a moment, with a >>> big smile. Saves a lot of typing when frobbing around. >> >> I stumbled on this feature by accident. Like most users, I didn't read >> the help file. (Heh.) >> >>> I'm entirely in agreement that IDLE should be an IDE for beginners. >>> >>> If you want to re-imagine a beginner's cross-platform Python IDE, go for >>> it. But choose your own name if you are going to really tear it up, >>> please. >>> It's more important to fix the IDLE bugs and make it really solid for >>> beginners on all platforms, IMO. And avoid creeping features. >> >> Feature-creep is something I definitely want to avoid. I've added a >> list of features that IR would explicitly *not* have, as way to set >> expectations of scope: >> https://github.com/asweigart/idle-reimagined/wiki/Why-Use-the-Existing-IDLE-Codebase%3F >> >> The major new features in the IR design would be the simplified >> real-time lint and post-to-pastebin feature. They're a lot of work, >> but I think they'll provide a huge payoff as well. But yeah, fixing >> bugs should take priority over implementing major features (which >> themselves will have new bugs). Currently I'm doing some design >> sketches, but mostly reading through the IDLE code base, reading >> through the idle-dev archive, and poking around on the Python issue >> tracker. >> >> Big, fancy features come after the simple improvements. >> >>> Guido had good reasons for his choices, I think. >>> >>> There was a long thread on python-dev awhile back, here's one post: >>> >>> https://mail.python.org/pipermail/python-dev/2013-March/124842.html >> >> I read through the thread. Whether or not IDLE development is spun off >> into a separate project (I don't know enough about IDLE's development >> yet), I agree with GvR that IDLE should stay in the distribution. >> >> I don't mean to step on toes, and I understand how overly-idealistic >> it looks for an outsider to come in and express several ideas for >> changes at once. (And, again, none of the suggestions I make are >> intended to be deeply staked into the ground.) But I see a lot of >> potential for IDLE coming from a UI design and Python educator >> background as far as lowering the barrier to entry for new users. >> >> It'll probably be about mid-January before I broach this topic again. >> I was just poking to see if there was interest on the idle-dev list >> for people who wanted to take a look at the initial ideas. In the >> meantime, I'll be familiarizing myself with the IDLE code base and the >> issue tracker more. >> >>> -- >>> KBK >>> _______________________________________________ >>> IDLE-dev mailing list >>> IDLE-dev at python.org >>> https://mail.python.org/mailman/listinfo/idle-dev >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> https://mail.python.org/mailman/listinfo/idle-dev > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow From tjreedy at udel.edu Sat Dec 27 19:24:33 2014 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 27 Dec 2014 13:24:33 -0500 Subject: [Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?] In-Reply-To: References: <1419398962.45199.206345409.5BEBCAEF@webmail.messagingengine.com> <8C12D274-EF07-4830-8FAE-40DFE2B0ED36@gmail.com> Message-ID: On 12/26/2014 7:11 PM, Sean Felipe Wolfe wrote: > it. As I recall, a lot of these fixes are actually code complete but > just need verification and inclusion in the next Python version. For > example, making the shell more terminal-like, eg. having an > out-of-focus keystroke take you to the >>> prompt and begin typing -- > this fix is actually done for a while but just hasn't been included. I > actually applied the patch manually myself and it's working well. I presume you are referring to http://bugs.python.org/issue2704 The problem with this issue is that there are multiple sub-issues and no consensus on making the changes. -- Terry Jan Reedy