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

[Al Sweigart]

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