> 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@python.org
https://mail.python.org/mailman/listinfo/idle-dev
