j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 2/20/2013 9:30 AM, Nick Coghlan wrote:
On Thu, Feb 21, 2013 at 12:04 AM, Barry Warsaw email@example.com wrote:
On Feb 20, 2013, at 04:10 PM, Steven D'Aprano wrote:
We could have a stable version of IDLE in the std lib, and another version available on PyPI. The PyPI version could change more rapidly, since it doesn't have to fit in with the release schedule for the std lib. As the release schedule allows, the two branches could be merged.
I have no idea if this has been tried before, but I think this would work better for an application like IDLE than for a library.
There's some precedence for this I think, e.g. mock, unittest2, email.
This was the plan for packaging vs distutils2, and I'll be proposing something similar for distlib, too.
It can be a little tricky to manage at times, but you can do truly experimental features in the PyPI version first with a warning that they're experimental (e.g the various incarnations contextlib.ExitStack went through when I first added it to contextlib2), while bug fixes and features you're more confident about can go directly into hg.python.org and then be published early through the downstream project.
Most of the actual issues that prompted this proposal are minor changes, such as to the find or replace dialog. Some might even be considered bug fixes rather than enhancements, depending on one's interpretation of the vague doc for such. This PEP is partly about whether we need to classify such changes, or just put them into whatever release we feel appropriate. Whatever the decision, those changes should directly go into whatever version they are going to go in.
On the other hand, I agree that a PyPI preview release of a rewrite of IDLE to use the newer ttk widgets would be a good idea. But I personally would base such a project on 3.3 and consider whether it should require tcl/tk 8.6 rather than 8.5. And I would only put it in the stdlib in a new release (perhaps alongside the existing IDLE for at least one release). So this PEP is not relevance to such a project.
-- Terry Jan Reedy