On 3/21/2013 12:32 AM, Kurt B. Kaiser wrote:
Well, spending a lot of time backporting new features is not my idea of
fun. OTOH, I have no objection.
I intentionally did not say in the PEP that it should be mandatory.
Along those lines, I've thought that IDLE should refrain from using the
newest features in Python, to allow people running released versions of
Python to access the newest IDLE. i.e. Python 3.4 innovations would not
be used in IDLE 3.4. Only Python 3.3 and earlier innovations.
So far, since 3.0/1, that has been a moot point. 3.2 was syntax frozen.
3.3 has 'yield from', but I do not know if there is much of anywhere
that *could* be used, and for simple uses, the old 'for i in it: yield
i; is good enough.
I don't know if this is the place to comment on PEP 434 (is it?), but
I've always taken the approach that IDLE development should be less
formal than the rest of stdlib, since it's not a dependency. Big
changes should be reserved for the tip, but I don't see why something
like the right click menu change shouldn't be backported.
Thank you for confirming my impression of your approach. When the right
click changed was challenged, I claimed that an *informal* relaxed
approach was the defacto rule. Antoine said that that was not OK and
Nick agreed and said that a relaxed approach would have to be
*formalized* in a PEP and approved. Then there would be no (less ;-)
arguments about IDLE pushes. Todd took the initiative to write a first
draft and I revised it.
I think we should try a more relaxed idlelib development process inside
core before we move it out, and should be generous about adding checkin
permissions for that purpose. Rietveld will help. It's a good way to
habilitate new developers.
I have commented over the years, but lately I've been so distracted by
the Treasurer job that I haven't found much time for IDLE.
So I should be selective in specifically asking for comment.
I've tried to channel Guido over the years. I looked at what he did,
and tried to project forward.
IDLE-dev is still active. Would anyone else like to be a moderator?
Yes. I presume that is the one mirrored as gmane.comp.pythong.idle. It
has been mostly quiet since September. When we have an accepted ground
rule for making decisions, I expect more discussions. For instance, I
think it might be the appropriate place to get input from interested
users about preferred behavior on a specific issue.
http://mail.python.org/mailman/listinfo/idle-dev
is out of date in places.
Without a vision and design document, it is sometimes hard for someone
like me to know which is which.
IDLE development has always been organic, as opposed to the formal
approach of the PEPs. What we need is a Zen of IDLE. When I look at
it, I see a simple IDE. I try to adhere to the principle of least
surprise, and to maintain an uncluttered interface suitable for
beginners. Expert features can be there, but somewhat hidden (though
they should be documented!) or implemented as disabled extensions.
IDLE tries to promote Pythonic style. For example, the lack of a
horizontal scroll bar was deliberate, I think.
We should implement the patch that adds an extension selector to the
options dialog, and keep the expert features as disabled extensions.
In all versions, I presume ;-).
I have been wondering if there are any beginner features implemented as
extensions that should be directly incorporated and planned to ask Roger
on idle-dev. Anyway, I like that idea as it lets us somewhat have the
cake of simplicity and also eat the cupcakes of expert features as desired.
That way, an instructor could distribute an idlerc file which would set
IDLE up exactly as desired, including links to course specific help
files on the web.
That would be excellent.
BTW, I'll take this chance to promote the use of idlelib/NEWS.txt for
IDLE news, instead of Misc/NEWS. That way, if IDLE is used outside of
the main release, the NEWS.txt will go with it.
Thanks for the reminder. That came up here on pydev recently and it was
agreed that IDLE should indeed go in the idlelib/NEWS and that the
release manager or someone could then *copy* it into Misc/NEWS as a
separate *** IDLE *** section. Or maybe the idea was vice versa. Either
was, this would avoid NEWS conficts for IDLE patches (unless multiple
IDLE developers pushed nearly simultaneously).
http://bugs.python.org/issue17506
Stability is paramount.
No surprises beats cool.
KISS is better than full featured.
Uniform trumps native look.
Experts go to the rear.
Where they can find what they want if they know where to look.
IDLE tests tkinter.
Thanks. I am glad I asked.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
