original) (raw)
(On Wed, Mar 20, 2013 at 12:51 PM, Xavier Morel <python-dev@masklinn.net> wrote:
The problem with it is, well, that it's a separate project so unless itOn 2013-03-20, at 20:38 , Barry Warsaw wrote:
\> On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote:
\>
\>> Agreed that the "sync into stdlib" think should not happen, or should at
\>> best be a temporary measure until we can remove idle from the source
\>> tarball (maybe at the 3.4 release, otherwise at 3.5).
\>
\> Right. �Ultimately, I think IDLE should be a separate project entirely, but I
\> guess there's push back against that too.
is still packaged in (in which case it's not quite separate project,
just a separate source tree) it's got to be downloaded and installed
separately.
That would be a blow to educators, but also Windows users: while the CLI
works very nicely in unices, that's not the case with the win32 console
which is as best as I can describe it a complete turd, making IDLE a
very nice proposition there (I never use IDLE on Linux or OSX, but do
all the time in Windows). It also provides a rather capable (and in many
case sufficient) code editor for a platform which lacks any form of
native text editor allowing sane edition of code.
Installing the Python windows packages and having everything "work" (in
the sense that you can immediately start writing and running python
code) is � I think � a pretty big feature.
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
FWIW, I specifically suggested that IDLE still gets packaged with Python releases for Windows. This shouldn't be hard, because IDLE depends on Python rather than the other way around. Packaging is not what I'm against. Maintaining this project's source within the Python core \*is\*.
I would be interested to hear Martin's opinion on this, as he's producing the Windows installers.
Eli
P.S. other Python distributions like ActiveState already bundle additional projects with their Python releases (pywin32 if I'm not mistaken).