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
