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

The problem with it is, well, that it's a separate project so unless it
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.

Oh, and another thing. If a Windows user wants a good Python shell, IDLE should be his last choice. There's Spyder, there's IPython, there's probably a bunch of others I'm not aware of.
">

(original) (raw)


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

The problem with it is, well, that it's a separate project so unless it
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.

Oh, and another thing. If a Windows user wants a good Python shell, IDLE should be his last choice. There's Spyder, there's IPython, there's probably a bunch of others I'm not aware of.


This is for IDLE as a shell. The same can be said for IDLE as an editor.

This is precisely my main gripe with IDLE: it does a lot of things, but neither of them it does well. It stomps in place while "competition" moves fast forward. If someone cares about it, that someone should fix it and improve it, quickly. The speed required for such improvements is unrealistic for Python core.


Eli