> 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.
�
">

(original) (raw)


\> � � On Mar 20, 2013, at 12:38 PM, Barry Warsaw <barry@python.org
> � � barry@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