[Idle-dev] IDLE in UK Schools

[Mark Roseman]

> 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