[Python-Dev] IDLE in the stdlib (original) (raw)
Eli Bendersky eliben at gmail.com
Wed Mar 20 20:46:25 CET 2013
- Previous message: [Python-Dev] IDLE in the stdlib
- Next message: [Python-Dev] IDLE in the stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson <benjamin at python.org>wrote:
2013/3/20 Barry Warsaw <barry at python.org>: > On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote: > >>IDLE would be a great first foray into this "separate project" world, >>because it is many ways a separate project. > > I really think that's true. A separate project, occasionally sync'd back into > the stdlib by a core dev seems like the right way to manage IDLE.
I would advise against this. Basically, every "externally-maintained" package with have causes pain. For example, the stdlib now has some long-diverged fork of simplejson. With xml.etree, it was not clear for years whether core developers could touch it even though the external project had died. Either the stdlib and IDLE should go separate ways or development has to happen in the stdlib with CPython release schedule and policies.
There are other dependencies like libffi, but I really think IDLE is different. xml.etree and libffi are building blocks upon which a lot of users' code depends. So we have to keep maintaining them (unless there's some sort of agreed deprecation process). IDLE is really a stand-alone project built on Python. It's unique in this respect. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130320/9638c570/attachment.html>
- Previous message: [Python-Dev] IDLE in the stdlib
- Next message: [Python-Dev] IDLE in the stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]