Guido van Rossum <guido@python.org> writes: [loewis] >> What is the current procedure for changing IDLE, for Python >> committers? Can I just commit changes to Lib/idlelib, do I need to >> post them to idle-fork, or do I need to do something else? >> >> [assuming, of course, that I think the change is sensible, and >> I would consider applying it to be within my competence] > > That's a good question; I'd like to see Kurt Kaiser's opinion on > that. I doubt that it will be different than for any other part of > the Python library though: when in doubt, use a SF patch or email the > current maintainer. Exactly that. IMHO we should emphasize stability, user-friendliness, low surprise factor, and performance over features. IDLE is the first exposure to Python for many people, and it should be a good, solid experience. IMHO, as with Python, only the experts should be able to find (or even stumble across) the expert features :-) This is not to say that IDLE should become static. There is much to do. Right now we're in beta mode, so, as with Python itself, we should hold off on significant feature implementation and concentrate on correctness and stability. If you start on a bug, please assign it to yourself. I've added Martin to IDLEfork, anyone else, just ask. But the bugs and patches are hopefully going to zero there and anything new should be posted to the Python trackers. If you work on a feature, it's helpful to mention it somehow so we don't step on each other. IDLE is big enough that people tend to concentrate on certain areas: I was working on the RPC / subprocess / debuggers and Stephen was working on the configuration system. > Fixing clear and simple bugs without asking first would be fine, > presumably; when you get in the feature business, a discussion first > would be appropriate. There's a TODO.txt file that lists things that > are presumably fair game (although again feature design should always > go through some discussion first). Idle-dev continues to be the place for discussion. (I do of course follow Python-dev and Python-checkins.) IDLEfork RIP. I will release Version 1.0 when 2.3 comes out and then go into bug fix mode to support the 2.2 userbase. __ KBK
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4