[Python-Dev] IDLE in the stdlib

[Eli Bendersky]

> >     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>