[Python-Dev] IDLE in the stdlib
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 <
> > webpage
> > automatically has IDLE. That is why I frequently teach Python with
> > If this thread results in IDLE being ripped out of the standard
> > then I would likely never use it again.
> > Why is it necessary to conflate distribution and development. "standard
> > != "Python distribution".
> Because that's how CPython defines its distribution. We distribute things
> 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
> > Take the ActivePython distribution for example. They ship with extra
> > for Windows (pywin32, etc) and our Python installer doesn't. This is a
> > many Windows people prefer ActivePython. That's their right, but this
> > 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
> 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
> > contribute to, which will hopefully result in a quicker pace of
> Why? You won't magically gather more people that are interested in IDLE
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev