2013/3/20 Barry Warsaw <barry@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.
">

(original) (raw)

On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson <benjamin@python.org> wrote:
2013/3/20 Barry Warsaw <barry@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



�