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 <sarah.kuchin...@gmail.com> 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 <a...@inventwithpython.com> wrote: >> >>> On Tue, Dec 23, 2014 at 9:29 PM, Kurt B. Kaiser <k...@shore.net> 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@python.org >>> https://mail.python.org/mailman/listinfo/idle-dev >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev@python.org >> https://mail.python.org/mailman/listinfo/idle-dev > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@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 _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev