[Idle-dev] IDLE in UK Schools

[Al Sweigart]

And to echo Mark and Guido, IDLE's prime benefit is that it is bundled with
Python. We should definitely be open to make large design changes to
benefit new programmers. Adding another checkbox to the configuration
window makes IDLE more versatile, but it also brings it closer to a VCR
with 50 buttons instead of an iPod with just the circle-wheel button.
That's the opposite of what new programmers (both kids and adults) want.

On Wed, Aug 5, 2015 at 3:11 PM, Al Sweigart <al at inventwithpython.com> wrote:

> To be clear, I don't want to fork IDLE. The prime benefit of IDLE is that
> it is bundle in Python installers and requires zero configuration. Forking
> it would indeed be a waste of energy (there are already plenty of good IDEs
> out there, and IDLE shouldn't even try to compete with them).
>
> I'll start going through the issue tracker for other IDLE features and
> link to them from the wiki. I'm not surprised that a lot of things I
> brought up in the IDLE Reimagined doc are already on the issue tracker.
>
> I meant "pastebin" as in the generic sense, rather than specifically
> pastebin.com. We'd of course have to work out the details of where these
> pastes would be hosted. But the idea here is to make it easy to share code
> without getting the whitespace mangled.
>
> If changing Python's error messages isn't a problem, then that'd be a nice
> freebie for IDLE. I only hesitated proposing this because I didn't know if
> these messages were cast in stone, due to Python code out there relying on
> the exact error message strings.
>
> I saw on the issue tracker that the pep8 style checker
> http://bugs.python.org/issue18704 had been set to "rejected" resolution a
> couple years ago. I don't mean to be misleading. I'm not against a style
> checker feature if not on by default, imo. By "real time lint", I meant a
> feature that could point out syntax errors and variable name typos, rather
> than code style.
>
> IDLE itself is already a standalone tkinter app, and any Python tutorial
> system itself would need an IDE anyway. Having an IDE bundled with the
> language itself makes Python stand out from all other languages. Having
> something to train the next generation of Python coders that doesn't
> involve typing code into a website would be excellent for the language, imo.
>
> Thanks for your patches and hard work, Terry. I've filed a bug for the
> "detect disk changes" feature: https://bugs.python.org/issue24799 Do post
> your ideas to the bug tracker. After August, I'll have much more time to
> spend on IDLE. I don't mean to only talk about ideas, I just wanted to have
> a plan before I start writing patches.
>
> -Al
>
> On Wed, Aug 5, 2015 at 12:43 PM, Mark Roseman <mark at markroseman.com>
> wrote:
>
>> > As a user of Idle for several years, and not a beginner, I disagree
>> with 'only'.  That aside, I consider it unnecessary and diversionary from
>> the numerous known issues that will benefit *everyone*.
>> > Most of the "features that will distinguish IR", so he claims, are
>> issues on the tracker awaiting commit ready patches.
>>
>>
>> I’m new here, and really want to avoid stepping on toes. Open source has
>> its own way of doing things, and a hesitancy to accept changes if there is
>> opposition. Which too often leads to a proliferation of options and
>> features, rather than design.  And because these projects aren’t resourced
>> like a ‘typical’ project, the notion of ‘enforcing’ priorities is kinda
>> mushy.
>>
>> If IDLE is to be a *great* tool for learning out of the box, anything
>> that distracts from or interferes with that purpose shouldn’t (appear to)
>> be part of it.  Examples would include most configuration, including:
>>         * the notion of extensions, especially installing,
>> enabling/disabling or configuring them
>>         * choosing or editing key sets
>>         * customizing syntax highlighting (though choosing from some
>> built-in themes might be an option, more likely dark vs. light background)
>>         * likely font changes (except for increase/decrease size)
>>
>> If there is actual agreement that IDLE’s main purpose is to be a great
>> learning tool, but to allow for some additional support for ’non-learners’,
>> it doesn’t preclude any of those things being around, but they shouldn’t be
>> there out of the box (think turning on a power user mode). Extra work in
>> terms of development, and increased maintenance, but in the free labour
>> economy, if someone wants to do it, and it can be done in a way that
>> doesn’t diminish the primary goal, it’s probably not a horrible thing.
>>
>> (I raise those examples as improving the existing dialogs is something
>> I’m willing to do if there’s interest and to reduce friction, but would be
>> the first person to say most of that stuff should be completely hidden out
>> of the box, and it would be ok with me if power user configuration, if
>> supported at all, involved manually editing config files.)
>>
>> To put it another way: how would a bug report and patch be received to
>> remove the ‘Configure Extensions’ dialog from the menu? Or remove the
>> ‘Keys’ tab from preferences dialog?
>>
>> That doesn’t preclude all those things being part of the architecture, or
>> for example a plugin architecture being created to hook in code checkers.
>> But out of the box, if a code checker is something that will help learners,
>> it should just be there automatically, and no messing around choosing,
>> installing or configuring one.
>>
>> Or if there is a choice of two user interaction models (A and B), where A
>> will work very well for learners but not at all for non-learners, and B
>> will work ok for both learners and non-learners, the app should support A
>> out of the box, with B nowhere to be seen. If someone really wants, a
>> choice between A and B can still be in the code and maybe exposed in ‘power
>> user’ mode if its there.
>>
>> Even in open source, there can be a cost to not making choices so you can
>> support more diversity. Trust me, I cringed through the Tcl’s community
>> refusing to standardize on a single object system for years. ;-)
>>
>> Mark
>>
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/3fdb68ba/attachment.html>