> Terry Reedy <tjre...@udel.edu> wrote: > > Al Sweigart wrote: >> We should definitely be open to make large design changes to benefit new >> programmers. > > I have been dreaming of and working toward this for 5 years. > Yet, we (I) constantly get requests to add options, or to add features that > will only be added if made optional. > Until this week, I have never seen a request to remove options.
As you know, I’m a firm believer in the notion that if you try to be all things to everyone, you don’t end up doing a very good job for anyone. And from my background in HCI, I know that every (visible) feature added has a cognitive cost associated with it. One of the stumbling blocks to experimenting with simplified or other interaction models, and why people feel a need to fork IDLE entirely, is that there are some rather monolithic pieces to the code that make fine-grained changes or reuse in novel ways difficult. What we can consider ‘model’ and ‘view’ code is pretty intermingled. Coupling is high and cohesion is low. I’m guessing that’s one of the reasons the whole extension thing came about, as an effort to not make it worse. I’d glad some testing was added. This will help if we are to make the architectural changes needed to incorporate new designs. Which has the potential to break things, but is necessary. Mark p.s. speaking of testing, I’m genuinely curious… has anyone (yourself, with students, or others you know) really used IDLE on OS X? _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
