[Idle-dev] Re-imagining IDLE [was: Re: idle-dev posts being held in moderation?]

Fri Dec 26 23:39:53 CET 2014

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 <al at inventwithpython.com> wrote:
> 
>> On Tue, Dec 23, 2014 at 9:29 PM, Kurt B. Kaiser <kbk at 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 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