j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Feb 20, 2013, at 6:04, Barry Warsaw firstname.lastname@example.org 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.
Personally, I've found it easier to track down certain changes in sqlite3 than in other modules. The Python docs are very clear about when a new function was added, but not always as clear about, e.g., performance characteristics or internal behavior with indirect external effects. I've found it easier in some cases to find that I'm relying on, say, pysqlite >= 2.5.0 behavior than python >= 2.6. And then mapping pysqlite >= 2.5.0 to Python versions is easy. And this might be even more relevant for IDLE than for a module.
And of course it gives me a way to deal with the changes. On a machine that has 2.5, I can just pip install pysqlite. And I can certainly see it being useful to pip-3.3 install idle to get IDLE 3.4.1 on a machine with python 3.3.
I don't think these are _major_ selling points, but they're at least minor ones, which may help counter the obvious downside (merging isn't free).