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

Reply via email to