[Python-Dev] IDLE in the stdlib (original) (raw)

Eli Bendersky eliben at gmail.com
Thu Mar 21 13:22:40 CET 2013

> On Mar 20, 2013, at 12:38 PM, Barry Warsaw <barry at python.org_ _> <mailto:barry at python.org>> wrote: > >> Right. Ultimately, I think IDLE should be a separate project entirely, but I >> guess there's push back against that too. > > The most important feature of IDLE is that it ships with the standard library. > Everyone who clicks on the Windows MSI on the python.org <_ _http://python.org> > webpage > automatically has IDLE. That is why I frequently teach Python with IDLE. > > If this thread results in IDLE being ripped out of the standard distribution, > then I would likely never use it again. > > > Why is it necessary to conflate distribution and development. "standard library" > != "Python distribution".

Because that's how CPython defines its distribution. We distribute things that are in the CPython/standard library repo, and nothing else.

Yes, I realize this is the case. I was wondering whether it's hard to change.

> Take the ActivePython distribution for example. They ship with extra packages > for Windows (pywin32, etc) and our Python installer doesn't. This is a reason > many Windows people prefer ActivePython. That's their right, but this preference > is not the point. The point is that it's perfectly conceivable to ship IDLE with > Python releases on Windows, while managing it as a separate project outside the > CPython core Mercurial repository. And what's the benefit? I just don't see it. It just makes it harder to create a Python release. This is the feedback I was looking for. If this will make Python distribution non-trivially harder, then it's a point against the proposal.

> This seems to me to combine benefits from both worlds: > > 1. IDLE keeps being shipped to end users. I have to admit the reasons made in > favor of this in the thread so far are convincing. > 2. IDLE is developed as a standalone project. As such, it's much easier to > contribute to, which will hopefully result in a quicker pace of improvement.

Why? You won't magically gather more people that are interested in IDLE development.

But that's the point - If there are not enough people interested in it, it should then die. Right now it's a burden of Python core developers to keep it functional even if no one else cares (and if anything, the low amount of open issues Terry quoted elsewhere may be a sign that indeed not many care).

> The > only demand is that it keeps working with a release version of Python, and this > is pretty easy. It's even possible and easy to have a single IDLE version for > Python 3.x instead of contributors having to propose patches for 3.2, 3.3 and > 3.4 simultaneously. They don't anyway.

But we know perfectly well that a core dev is expected to backport reasonably. In an outside repo, it can have a single-code base. It's not hard to avoid the new features of 3.3 and 3.4 and be compatible with all active Python 3 versions. Note that even if the same is done in our Mercurial repo, each commit still needs to be triplicated in the push dance.

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130321/20ee37ec/attachment.html>

More information about the Python-Dev mailing list