On Wed, Mar 20, 2013 at 10:11 AM, Todd Rovito wrote:

...

Interesting writeup about PyCon 2013 young coder education: http://therealkatie.net/blog/2013/mar/19/pycon-2013-young-coders/

Quote:

"We used IDLE because it's already on Raspian's desktop. Personally, I

...

IDLE as a teaching tool. It's included in the standard library, it does tab completion and color coding, and it even has a text editor included so you don't have to start your class off by teaching everyone about paths.

Too bad it's broke as hell."

Personally, I think that IDLE reflects badly on Python in more ways than one. It's badly maintained, quirky and ugly. It serves a very narrow set of uses, and does it badly.

Being part of Python *distributions* and being part of core Python standard library are two different things. The former may make sense, the latter IMHO makes no sense whatsoever. Outside the Python core IDLE can be maintained more freely, with less restrictions on contributors and hopefully become a better tool. Eli, Thanks for sharing that article it was a fun read. I think the next paragraph from the article is important as well: "I believe my first contribution to the Python Standard Library will be fixes to IDLE. I really do like it that much. Happily, the kids were flexible. If they needed to do a workaround, or ignore something on our slides (they were written with the standard shell in mind),

On Wed, Mar 20, 2013 at 12:41 PM, Eli Bendersky wrote: like they did so. They were total champs. My adult students would have been much more upset."

Having an IDE that ships with Python is powerful and follows Python's mantra "batteries included". Personally I think removing IDLE from the Python Standard Library is a mistake. IDLE helps the novice get started as demonstrated by this article. What is frustrating is many patches already exist for IDLE in the bug tracker they simply have not been committed. PEP-434 (http://www.python.org/dev/peps/pep-0434/) is designed to make it easier to get these patches committed. I would ask that you give PEP-434 some time and let the process work before we start a in-depth discussion on if IDLE should stay or go.

Todd, note that I did not propose to remove IDLE from Python distributions, just from the Python core (Mercurial repository, to be technically precise). This is a big difference. Outside the Python core a more free-moving community can be built around developing IDLE. I've seen PEP 434, but it's far from being enough. I just don't think there are enough core devs with the time and desire to review IDLE patches (especially non-trivial ones). Outside the Python code, this can be relaxed. And Python distributions can still bundle some stable IDLE release. Eli

On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:

IDLE would be a great first foray into this "separate project" world, because it is many ways a separate project.

I really think that's true. A separate project, occasionally sync'd back into the stdlib by a core dev seems like the right way to manage IDLE. -Barry

On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson wrote:

2013/3/20 Barry Warsaw :

...

On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:

...

IDLE would be a great first foray into this "separate project" world, because it is many ways a separate project.

I really think that's true. A separate project, occasionally sync'd back into the stdlib by a core dev seems like the right way to manage IDLE.

I would advise against this. Basically, every "externally-maintained" package with have causes pain. For example, the stdlib now has some long-diverged fork of simplejson. With xml.etree, it was not clear for years whether core developers could touch it even though the external project had died. Either the stdlib and IDLE should go separate ways or development has to happen in the stdlib with CPython release schedule and policies.

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). The main thing I like about the separate project idea is that, given that only a small group of people care about IDLE, it is much more satisfying for them to be able to release IDLE separately to their user community regularly (every month if they want to) rather than being held to the core Python release schedule and practices. We should deal with compatibility obligations of the stdlib in the usual way, though maybe we can just delete it in 3.4, since few people presumably use idlelib apart from IDLE itself. Binary distributions from python.org should still include IDLE (and Tcl/Tk) -- however we should switch to bundling the separate project's output rather than bundling the increasingly broken version in the stdlib. What other distributors do is outside our control, but we ought to recommend them to do the same. -- --Guido van Rossum (python.org/~guido)

On Wed, Mar 20, 2013 at 12:38 PM, 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.

I didn't hear any at the sprint here. -- --Guido van Rossum (python.org/~guido)

On Wed, Mar 20, 2013 at 3:54 PM, Barry Warsaw wrote:

On Mar 20, 2013, at 12:40 PM, Guido van Rossum wrote:

...

I didn't hear any at the sprint here.

JFDI! :)

-Barry

+1 why are we still talking show me the patches

On Wed, 20 Mar 2013 15:05:40 -0700 Nick Coghlan wrote:

Yes, the status quo of Idle is not something we should allow to continue indefinitely, but decisions about its future development should be made by active maintainers that are already trusted to make changes to it (such as Terry and Roger), rather than those of us that don't use it, and aren't interested in maintaining it.

Definitely. People shouldn't remain quiescently torpid about the idle status quo. Regards Antoine.

Am 21.03.2013 00:47, schrieb Barry Warsaw:

On Mar 20, 2013, at 11:11 PM, Antoine Pitrou wrote:

...

On Wed, 20 Mar 2013 15:05:40 -0700 Nick Coghlan wrote:

...

Yes, the status quo of Idle is not something we should allow to continue indefinitely, but decisions about its future development should be made by active maintainers that are already trusted to make changes to it (such as Terry and Roger), rather than those of us that don't use it, and aren't interested in maintaining it.

Definitely. People shouldn't remain quiescently torpid about the idle status quo.

The release managers should have a say in the matter, since it does cause some amount of pain there.

I don't really understand what Antoine's "quiescently torpid" means, but splitting IDLE out to a separate repo and then merging it back every time a release rolls around sounds stupid. Either split it off completely or develop it here (my preferred solution). It's really not that hard to get CPython commit bits. Georg

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

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.

On 2013-03-20, at 20:59 , Brian Curtin wrote:

On Wed, Mar 20, 2013 at 2:51 PM, Xavier Morel wrote:

...

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

Can you explain this a bit more? I've been using the CLI python.exe on Windows, Mac, and Linux for years and I don't know what you're talking about.

Windows's terminal emulator (the "win32 console")'s deficiencies don't break it for running existing script, but make using it interactively a rather thankless task, at least as far as I'm concerned: no readline keybinding (e.g. C-a & C-e), very limited scrollback, fixed width, non-handling of signals (C-d will simply print ^D, a syntax error), odd copy behavior (rectangle copies *only*), etc…

On Wed, Mar 20, 2013 at 12:51 PM, Xavier Morel wrote:

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

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

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

On 2013-03-20, at 21:14 , Eli Bendersky 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.

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.

Sure, there are plenty of tools for the experienced python developer with reasons to invest time in a windows development setup, but IDLE provides an acceptable low-cost and low-investment base which is *there*: it does not require spending a day downloading, trying out and getting familiar with a dozen different Python IDEs, it's simple and for the most part it works. I view it as an mg, not an emacs, if you see what I mean.

Eli Bendersky writes:

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.

Actually, there are surprisingly little competition to IDLE as a shell! IDLE has mostly working multi-line editing and history, while most "sophisticated" environments (including Spyder) work line-by-line, which makes defining a function (let alone a class) in the shell prohibitively painful. The only other shells I could recommend to a beginner are: 1. IPython, which of course does multi-line editing superbly. Its non-standard extensions are a distraction and it's too far into power-user end of the spectrum to ever become a fits-all recommendation. The notebook is enough of a win to tip the scales for some educators, but the jury is still out if that's a smooth beginner experience. 2. Dreampie, designed by an ex-IDLE-contributor for the sole purpose of being a better shell than IDLE. However, lack of an editor makes it less practical as an introductory tool.

On Mar 20, 2013, at 12:38 PM, Barry Warsaw 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 IDLE. If this thread results in IDLE being ripped out of the standard distribution, then I would likely never use it again.

JFDI! :)

That is a comment from a person who uses Emacs every day. For those of us who have to support people with basic installs, it is essential that they have some Python aware editor on their machine. Without IDLE, a shocking number of people would create Python files using notepad. Raymond

On Wed, Mar 20, 2013 at 7:57 PM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:

On Mar 20, 2013, at 12:38 PM, Barry Warsaw 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 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". 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. 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. 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. Eli

Am 21.03.2013 19:13, schrieb Antoine Pitrou:

On Wed, 20 Mar 2013 19:57:54 -0700 Raymond Hettinger wrote:

...

On Mar 20, 2013, at 12:38 PM, Barry Warsaw 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 IDLE.

If this thread results in IDLE being ripped out of the standard distribution, then I would likely never use it again.

Which says a lot about its usefulness, if the only reason you use it is that it's bundled with the standard distribution.

Just like a lot of the stdlib, it *gets* a lot of usefulness from being a battery. But just because there are better/more comprehensive/prettier replacements out there is not reason enough to remove standard libraries. Georg

Am 22.03.2013 10:48, schrieb Antoine Pitrou:

Le Thu, 21 Mar 2013 21:38:41 +0100, Georg Brandl a écrit :

...

Am 21.03.2013 19:13, schrieb Antoine Pitrou:

...

On Wed, 20 Mar 2013 19:57:54 -0700 Raymond Hettinger wrote:

...

On Mar 20, 2013, at 12:38 PM, Barry Warsaw 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 IDLE.

If this thread results in IDLE being ripped out of the standard distribution, then I would likely never use it again.

Which says a lot about its usefulness, if the only reason you use it is that it's bundled with the standard distribution.

Just like a lot of the stdlib, it *gets* a lot of usefulness from being a battery. But just because there are better/more comprehensive/prettier replacements out there is not reason enough to remove standard libraries.

That's a good point. I guess it's difficult for me to think of IDLE as an actual library.

You're right, "library" is not a good term, but "battery" certainly is. Georg

On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson wrote:

2013/3/20 Barry Warsaw :

...

On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:

...

IDLE would be a great first foray into this "separate project" world, because it is many ways a separate project.

I really think that's true. A separate project, occasionally sync'd back into the stdlib by a core dev seems like the right way to manage IDLE.

I would advise against this. Basically, every "externally-maintained" package with have causes pain. For example, the stdlib now has some long-diverged fork of simplejson. With xml.etree, it was not clear for years whether core developers could touch it even though the external project had died. Either the stdlib and IDLE should go separate ways or development has to happen in the stdlib with CPython release schedule and policies.

There are other dependencies like libffi, but I really think IDLE is different. xml.etree and libffi are building blocks upon which a lot of users' code depends. So we have to keep maintaining them (unless there's some sort of agreed deprecation process). IDLE is really a stand-alone project built on Python. It's unique in this respect. Eli

On 3/20/2013 2:22 PM, Eli Bendersky wrote:

On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray mailto:rdmurray@bitdance.com> wrote:

On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky mailto:eliben@gmail.com> wrote:

...

Personally, I think that IDLE reflects badly on Python in more ways than one. It's badly maintained, quirky and ugly. It serves a very narrow set of uses, and does it badly.

Personally, I think running Python with the imitation-MSDOS Windows Command Prompt (CP) reflects badly on Python in more ways than one. It's anti-maintained, quirky and ugly, and for some uses is badly broken. I am serious and am not just being sarcastic. I suggested years ago that we try to find an alternative. Some details: Ugly (and quirky): it imitates ancient white type on black background CRT monitors. I do not know of anything else on Windows that looks like that. Broken (and quirky): it has an absurdly limited output buffer (under a thousand lines) that is over-flowed, for instance, by "python -m test". In other words, by the time the test suite has finished, the early results and error messages have scrolled off the top. Same can be true of verbose repository pulls, doc builds, external dependency fetch and compile, help messages, and any other substantial printing. For example, start the standard interpreter, enter 'help(str)', page down to the bottom, scroll back up, and the top of the help message is gone. *That* is real 'broken'. Quirky: Windows uses cntl-C to copy selected text to the clipboard and (where appropriate) cntl-V to insert clipboard text at the cursor pretty much everywhere. (Anti-maintained: I think Microsoft wants people to abandon unix-like command processing and that they are intentionally keeping CP ugly and disfunctional.) Now lets look at IDLE: Standard black (+ other colors) on white and close to standard gui. *Much* prettier than CP 'Unlimited' lines of code and output in windows. *Much* more functional in this respect. I cannot think of *anything* in IDLE that compares to the brokeness of CP in throwing output away. Standard ^C,^V behavior. To me, IDLE is much less quirky than CP. Oh, but it did have one quirk -- the right context menus lacked the standard Copy and Paste entries of Windows applications. When that was added for all versions, a couple of people challenged it as a default-only 'enhancement' rather than all-versions 'bugfix'. That challenge directly lead to PEP434. In last two months since, IDLE work has mostly stopped. I will say more about maintenance problems, but getting back to CP versus IDLE... From IDLE:

...

...

print('\x80') € print('\xc8') È

Impressed? You should be. Open Start menu / Python33 / Python (command line) and both of those result (modulo the specific character) in UnicodeEncodeError: 'charmap' codec can't encode character '\xc8' in position 0: character maps to <undefined> and we have not even gotten beyond latin-1, into the 'real' unicode char set, which IDLE supports MUCH better. For display, default United States CP is close to ascii-only. In summary: IDLE makes Python interactive mode tolerable and useful on Windows in ways where CP completely fails. If you are worried about something making Python look bad on Windows, target CP before IDLE.

Getting things committed in Python is not easy, and even if we get a sudden influx of good patches (which I doubt)

Given recent history, this is silly. A year and a few months ago, (Dec 2011, I think), I asked Roger Serwy to start submitting patches, with the promise to review and possibly commit some. Consequently, in the last year, we have *already* gotten a 'sudden influx of good patches'. It is true that I have not yet kept up my end of the bargain. One problem for me has been an inability to test IDLE patches on Windows with repository builds, due to the need for a working tkinter. It turns out that the pc build files are buggy and the devguide and the (to me confusing) pcbuild/readme do not have the workaround that was communicated to me only about 10 days ago.

these will take time to review and get committed.

In spite of my slowness, others have been active. Searching cpython/Misc/NEWS for ' IDLE ' (case-insensitive) returns 31 hits. For 4 months (Oct-Jan), that is pretty active, certainly much more active than in the years prior to 2012. As soon as PEP434 is resolved and Roger is fully on board, the pace will pick up again. At least a few people have been given commit privileges but never (or essentially never) exercised them. I think a couple were specifically for working on IDLE. I have not asked any of these people why, but I can imagine from my own experience that uncertainty over what is and is not allowed is one reason. I will discuss repository separation in another response, but request here that the still vague idea of doing something in the *future* not be used to stop PEP434, in whatever form, and current IDLE development *now*. -- Terry Jan Reedy

On 3/20/2013 8:38 PM, Neil Hodgson wrote:

Terry Reedy:

...

Broken (and quirky): it has an absurdly limited output buffer (under a thousand lines)

The limit is actually 9999 lines.

I clicked Start / All programs / Python 3.3 / Python (command line)

...

...

help(str) <space> (several times) and scrolled back up and the result was as I described. Help was gone above the 'c' methods. That is not 9999 lines.

I believe I later specified 'as installed'. But you are right. If one knows to right click on the blue and yellow Python snake, select Properties, Layout, and find Screen Buffer Size and Height, then one can increase the miserly default of 300 to 9999, at least on Win 7. 'Under a thousand lines' may be a vague memory from XP. I am also sure that with XP, the settings would revert for non-admin users after closing. Maybe MS did upgrade Command Prompt a bit. Oh, but we are not done with the stupidity of Command Prompt. If one does set the buffer to 9999 lines, it pads the output to 9999 lines and shrinks the movable scroll bar down to an eighth inch. If you move it. say, 1/20 of the screen, you jump 500 lines, which initially is way past your actually output. The standard 'modern' convenience of dynamically resized buffers and bars, such as found in the nearly 20 year old Notepad, is not for CP. (There is an idea for MS: junk CP and re-build a modern version on top of Notepad.) Setting properties by right clicking the icon is not standard on Windows. There is no help available from the window that I could find. I also could not find anything about the properties dialog in Windows help. If you can find an official entry for 'QuickEdit Mode' and 'Insert Mode', please let me know. Python Setup and Usage also says nothing about using the Command Prompt interpreter. -- Terry Jan Reedy

On 3/21/2013 5:27 AM, Paul Moore wrote:

Can I suggest that debates about the capability of Windows command line programming are off-topic here?

I respectfully disagree, unless you say that the whole thread is off topic. If it is okay for people to say that IDLE, including the IDLE interactive interpreter shell is ugly, quirky, broken, badly maintained, and disfunctional, without giving hardly any facts or details to back up or explain the claims, and then claim it is so bad that it should be banished, then to me it is perfectly on topic for me to point out that the alternative, the CP shell, is objectively far worse in multiple respects. Yes, I gave some facts for the benefit of those who were willing to consider my claim that IDLE is better.

it is what Windows users who use the command line are used to.

I bet that 'Windows users who use the command line' are less than 10% of Windows users. I am willing to accept that you find it adequate. Why can't you accept that I find it wretched, especially when I explained some of why rather than just throwing it out as an opinion, and consider IDLE to be wonderfully better? -- Terry Jan Reedy

Paul Moore writes:

I have no figures one way or the other on that. You may well be right. Are we aiming at "all Windows users" here?

We need to be careful about this. ISTM that IDLE is aiming at the subset of users on any platform who for some reason need/want a simple development environment that is consistent across Python versions and platforms and immediately available when they install Python, but don't have one yet. I think that there's been sufficient testimony to demonstrate that there are a fair number of folks in that boat. Educators (acting as proxies for a couple of orders of magnitude more students) are one identifiable group. Beginning Python users on Windows who don't use English in their daily lives and therefore need an environment that deals with the nightmare of "code pages" and "POSIX locales" are another.

My experience may well be atypical, I can't say.

I suppose it is reasonably typical. I'm sure everybody (by now, including Guido!) have many parts of the stdlib they just never need to use, nor does anybody around them. Most of us rarely to never want IDLE. That's not the point. The "batteries included" slogan is inaccurate in the sense that everybody needs batteries or their toys won't run. The batteries that slogan refers to aren't for everyone, rather the hope is that there are enough different batteries in the kit that everyone can get started. They can always get Twisted later.<wink/>

On 3/20/2013 8:15 PM, Terry Reedy wrote:

I will discuss repository separation in another response

Here is a radical idea I have been toying with: set up a 'common' repository to 'factor out' files that are, could be, or should be the same across versions. The 'common' files would be declared (especially to packagers, when relevant) to be a part of each branch. Each release would (somehow - not my department) incorporate the latest version of everything in 'common'. What would go here? Misc/ACKS: the sensible idea that there should only be one copy of this file has been discussed before. LICENSE: I believe this is the same across current versions and must be edited in parallel for all future branches. xxx: others that I have not thought of. Doc/tools (sphinx and dependencies): setting this up separately but identically for each branch is a bit silly if it could be avoided. The sphinx versions should, of course, be the new one that runs on both python 2 and 3. idlelib: already discussed. Having only one IDLE version would partially speed up development. (surely controvesial) tkinter and _tkinter: I think the _tkinter and tkinter for each release should work with and be tested with the most recent tcl/tk release. Having only one tkinter version might make having one version of IDLE even easier. (probably even more controversial) tcl/tk (or at least the files needed to fetch and build - but as long as the sources are on python.org anyway, the sources could also be moved here from svn): For IDLE to really work the same across versions, it needs to run on the same tcl/tk version with the same bugfixes. For example, over a year ago, a French professor wrote python-list or idle-sig or maybe both saying that he would like to use IDLE in a class in Sept 2012, but there was a bug keeping it from working properly with French keyboards. He wanted to know if we were likely to fix it. The first answer (provided by Kevin Walzer) was that it was a tcl/tk bug that he (Kevin) was working on. The fix made it into 8.5.9 a year ago and hence into 3.3 but 2.7.3 or 3.2.3, released a month after the fix. So I later told him he could use IDLE, but, at least on Windows, only with the then upcoming 3.3. (I don't know the tcl/tk version policy for the non-Apple builds.) I do not know if tcl/tk 8.5.z releases have added many features or are primarily bugfixes like our micro releases. If the latter, the case for distributing at least the most recent 8.5.z with windows would seem pretty strong. I also do not know what 8.6.z adds. But an tcl/tk 'enhancement' of supporting astral characters might look like a bugfix for IDLE. (Running from IDLE, print(astral_char) raises, but I believe the same code works in some Linux interpreters.) yyy: any other external dependencies that we update on all versions. --- Terry Jan Reedy

On 3/21/2013 2:06 AM, Philip James wrote:

I hope I'm not coming across as pedantic, because I think you have some good arguments listed above, but shouldn't discussion like this go in python-ideas rather than python-dev?

Normally yes. But since this is a counter-proposal or an alternate proposal to proposals already made in this thread, it belongs as an offshoot of this thread. This thread in turn is a continuation of similar threads here in the past, and involves some people who are less active in python-ideas. Also, it is more about technical development matters than about future *language* changes.

I'm very new to these lists, so forgive me if I'm stepping on any toes, I'm just trying to grok what kind of content should go in each list.

You are not stepping on my toes, and that is a good question to think about. -- Terry Jan Reedy

On 20 March 2013 23:53, Steven D'Aprano wrote:

I also note that in the last few weeks, I've seen at least two instances that I recall of a beginner on the tutor@python.org mailing list being utterly confused by Python's Unicode handling because the Windows command prompt is unable to print Unicode strings.

It can be worst than that - in i18nes Windows installs, the DOS Prompt sometimes have a different encoding than the Windows running - for example, for pt_BR Windows, all UI apps run using latin1, but the CP uses a CP850 encoding which generates _different_ characters for the same codes. As someone who form times to times lecture a introductory workshop of Python to people running Windows, I second Terry's long message - and I highlight Raymond's """ Without IDLE, a shocking number of people would create Python files using notepad. """ js -><-

Thanks Terry.

On 3/21/2013 12:36 AM, Glenn Linderman wrote:

On 3/20/2013 5:15 PM, Terry Reedy wrote:

...

Broken (and quirky): it has an absurdly limited output buffer (under a thousand lines)

People keep claiming that Windows CMD has a limited output buffer. It is configurable, at least to 9999 lines, which is where I have mine set. That is far too much to actually scroll back through for most practical purposes, although sometimes I do :)

See my response to the same point by Neil Hodgson, where I noticed that setting to 9999 lines somewhat disables easy scrolling. (I checked and it was 9999 also on XP.)

I'm not trying to claim that Windows CMD is wonderful, perfect, or has large numbers of redeeming values, but let's keep to the facts.

Yes, lets do. I tried to. A person who installs Python on Windows and runs Python (command prompt) instead of IDLE is confronted with a 300 line default. Someone not familiar with Command Prompt will not know that the limit can be increased. I use CP so seldom, until recently, that I had forgotten how to do so. I fiddled with the history buffer setting on the first page. That did not work so I gave up. -- Terry Jan Reedy

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy wrote:

On 3/20/2013 12:41 PM, Eli Bendersky wrote:

Personally, I think that IDLE reflects badly on Python in more ways than

...

one. It's badly maintained, quirky and ugly.

Ugly is subjective: by what standard and compared to what?

Compared to other existing Python IDEs and shells which are layered on top of modern GUI toolkits that are actively developed to keep with modern standards, unlike Tk which is frozen in the 1990s.

I suggested in my previous response why I think 'badly maintained' is untrue and/or unfair. Dismissing the recent work that has been done does not help.

I did not intend to dismiss your work Terry, and I'm sorry if it came out this way. You know that I also contributed bug fixes to IDLE in the past so I'm not a complete outsider. I see the value of IDLE being distributed with Python. However, especially in view of the recent developments in the area of alternative Python implementations, I think it's important to clearly mark the boundaries between things that belong in the core CPython code repository and things that don't.

There are 20 open issues with smtp(lib) in the title. It is 37 kb, making .54 issues per kb. For idlelib, with 786 kb, there are 104 issues, or .13 issues per kb, which is one fourth as many. I could claim that smtplib, based on 1990s RFCs is much worse maintained. It certainly could use somee positive attention.

You know better than I do that the number of open issues is not really the only factor for determining the quality of a module. Eli --

What current quirks, not already the subject of a tracker issue, are you thinking of?

...

It serves a very narrow set of uses,

Relative to the computing universe, yes. It focuses on editing and running Python code.

...

and does it badly.

As a user, I rate it at least 'good'. Most of the tracker issues hardly affect me, and many or most of the worst problems for me have already been fixed. What IDE would you suggest as a simple, install and go, alternative? It should have the following features or something close: * One-key saves the file and runs it with the -i option (enter interactive mode after running the file) so one can enter additional statements interactively. * Syntax errors cause a message display; one click returns to the spot the error was detected. * Error tracebacks are displayed unmodified, without extra garbage or censorship. # Right click on a line like File "C:\Programs\Python33\lib\**difflib.py", line 1759, ... and then left click on the goto popup to go to that line in that file, opening the file if necessary.

As of 3.3.0, this last feature was not documented, at least not in the Idle Help file. Since then, it has been.

-- Terry Jan Reedy

______________________________**_________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** eliben%40gmail.comhttp://mail.python.org/mailman/options/python-dev/eliben%40gmail.com

On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy wrote:

I think being frozen in the late 1990s is better than being frozen in the early 1980s, like Command Prompt is. In fact, I think we should 'deprecate' the Command Prompt interpreter as the standard interactive interpreter and finish polishing and de-glitching IDLE's Python Shell, which runs on top of the windowless version of CP with a true GUI. Then we can promote and present the latter as the preferred interface, which for many people, it already is.

Please don't cease supporting the command line interface. I use the command line interactive interpreter plenty. That way I can use git, grep, the unit test suite, etc. ... and the interactive interpreter, all from one place: the console. That can't happen with IDLE, by design. -- Devin

On 3/21/2013 5:41 AM, Paul Moore wrote:

On 21 March 2013 06:54, Devin Jeanpierre wrote:

...

On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy wrote:

...

I think being frozen in the late 1990s is better than being frozen in the early 1980s, like Command Prompt is. In fact, I think we should 'deprecate' the Command Prompt interpreter as the standard interactive interpreter and finish polishing and de-glitching IDLE's Python Shell, which runs on top of the windowless version of CP with a true GUI. Then we can promote and present the latter as the preferred interface, which for many people, it already is.

I should have prefaced that with 'on Windows'. I presume the command line on *nix is better with most of the issues I discussed than on Windows.

...

Please don't cease supporting the command line interface.

My one person opinion and counter-proposal is not going to change anything. Anyway, my two points were this: if late 1990s is bad, isn't early 1980s worse? And *if* we are going to one downplay/demote of the two interactive shells, should not it be the worse one?

...

I use the command line interactive interpreter plenty. That way I can use git, grep, the unit test suite, etc. ... and the interactive interpreter, all from one place: the console.

That can't happen with IDLE, by design.

It is Microsoft, not me, that is a threat to Command Prompt. I have the impression that it is not part of the Win 8 not-Metro tablet interface that they would like everyone to use even on the desktop. To push beginners away from the desktop to the pane interface, they were initially going to limit the free Visual Express IDE and compilers to the new interface. You can use idle from the command line almost as easily as the CP interpreter: 'python -m idlelib' instead of just 'python' (I just tried it to verify). Unlike bare 'python', IDLE includes a grep. Right click on any 'hit' and it opens the file at the specified line. Unlike bare 'python', you can run tests and collect the all the output, from as many tests as you want, in a dynamically right-sized buffer.

Agreed. Command line Python is 100% of my usage, and removing it would make Python unusable for me.

Whereas others would say the same about removing IDLE.

If what is being suggested is removing the "Python Command Line" *shortcuts*

I did not suggest that.

those shortcuts (and if I did, I could set them up myself). But before removing them, why not consider setting the defaults to be more helpful (larger scrollback buffer, things like quick edit set on, etc) if that's the real issue here? I'm not saying it is, but some of the complaints about "the default experience" *can* be fixed simply by changing the defaults.

If that is so easily possible, then it should have been done already. -- Terry Jan Reedy

On 3/22/2013 2:51 PM, francis wrote:

~$ python2.7 -m idlelib /usr/bin/python2.7: No module named idlelib.__main__; 'idlelib' is a package and cannot be directly executed

Same with python3...

C:\Programs>python33\python.exe -m idlelib brings up IDLE on Windows. 2.7 and 3.2 do not work as above but require 'idlelib.idle' instead of just 'idlelib'. C:\Programs>python32\python.exe -m idlelib.idle C:\Programs>python27\python.exe -m idlelib.idle I have no idea if the change is to '-m' processing or to idlelib. If the latter, it is an example of a patch that might have been harmlessly backported with PEP434 accepted. -- Terry Jan Reedy

On 3/21/2013 5:20 AM, Antoine Pitrou wrote:

Le Thu, 21 Mar 2013 02:42:33 -0400, Terry Reedy a écrit :

...

On 3/20/2013 11:54 PM, Eli Bendersky wrote:

...

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy

...

Ugly is subjective: by what standard and compared to what?

Compared to other existing Python IDEs and shells which are layered on top of modern GUI toolkits that are actively developed to keep with modern standards, unlike Tk which is frozen in the 1990s.

I think being frozen in the late 1990s is better than being frozen in the early 1980s, like Command Prompt is. In fact, I think we should 'deprecate' the Command Prompt interpreter as the standard interactive interpreter and finish polishing and de-glitching IDLE's Python Shell, which runs on top of the windowless version of CP with a true GUI.

And this may indeed be reasonable under Windows, where the command-line is a PITA!

Which is the only context I was talking about.

But the Linux command-line is actually quite very usable these days, especially if you configure your Python interpreter to use readline for tab-completion of identifiers (which should be done by default, see http://bugs.python.org/issue5845).

IDLE has tab-completion for both identifiers and attributes, in both shell and editor windows. It is probably under-documented; I am still learning to use it effectively. I am curious if the readline version works better in any way that IDLE could imitate. -- Terry Jan Reedy

On Thu, Mar 21, 2013 at 5:26 AM, Daniel Holth wrote:

I showed IDLE to my 6-year-old on the Raspberry Pi and I'm convinced it is cool. Gave up on trying to (slowly) install bpython. We were multiplying large numbers and counting to 325,000 in no time. It might not be for *me* but I'm not going to teach my daughter a large IDE any time soon.

This, 1000x this. It was helping out at the Young Coders tutorials that convinced me we need to continue shipping IDLE, or something like it, for use by *people learning to use computers as more than just passive consumers for the first time*. This means running well on Windows and the Raspberry Pi at this point. Keeping IDLE in the core represents a commitment to the use of Python as a teaching language both inside and outside of formal educational settings. We can refactor IDLE to make aspects of it easier to test with the buildbots, especially now that we have unittest.mock in the standard library to mock out some of the UI interaction in the test suite. (I'm happy to help coach the IDLE devs on that if they want to start improving the test suite coverage for the IDLE code) I think we should commit to making "start with IDLE" the recommended teaching experience, and then focus on *making that experience awesome*. Once people are already familiar with the language and what it can do for them, they may choose to move on to other tools, or they may decide to stick with IDLE. But deciding on "What is IDLE?" and "Why is it part of the CPython development repo?" is a necessary step to revitalising it and stopping the recurring discussions about taking it out. If Terry is willing to recast his PEP in that light, I think that would be a wonderful thing to do. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Thu, Mar 21, 2013 at 11:21 AM, Nick Coghlan wrote:

We can refactor IDLE to make aspects of it easier to test with the buildbots, especially now that we have unittest.mock in the standard library to mock out some of the UI interaction in the test suite. (I'm happy to help coach the IDLE devs on that if they want to start improving the test suite coverage for the IDLE code) Count me in where/when do we start? Can we perhaps setup a IRC chat with you?

On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote:

1. Whether IDLE should be developed separately from the core Python repository (while still being shipped).

I really want to constructively focus on (1).

In fact, solving (1) should help move along the discussions about separating the stdlib into a separate repo, for the benefit of alternative implementations. Agreed that there are many other issues to resolve in that latter discussion. But I think Eli is right that we should be thinking about how to develop code in separate repos and still ship a combined release. -Barry

Am 21.03.2013 16:23, schrieb Nick Coghlan:

On Thu, Mar 21, 2013 at 6:22 AM, Barry Warsaw wrote:

...

On Mar 21, 2013, at 05:25 AM, Eli Bendersky wrote:

...

1. Whether IDLE should be developed separately from the core Python repository (while still being shipped).

I really want to constructively focus on (1).

In fact, solving (1) should help move along the discussions about separating the stdlib into a separate repo, for the benefit of alternative implementations. Agreed that there are many other issues to resolve in that latter discussion.

But I think Eli is right that we should be thinking about how to develop code in separate repos and still ship a combined release.

I think a federated repo model in general is something we need to consider, it's not something we should consider IDLE specific.

Right. Without a coordinated plan this will go the road of elementtree or simplejson. Georg

On Thu, Mar 21, 2013 at 02:19:33PM -0700, Mark Janssen wrote:

The *only* thing I find "ugly" about it is that it doesn't have a white-on-black color scheme. Look at any hacker console and you won't find a white screen.

Call me a bad hacker or not hacker at all -- I hate black backgrounds. My windows are always black-on-lightgrey, sometimes on dark grey, never black. I have been spending 16 hours a day at the screen for last 25 years -- and never understood black background. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

I expressed this opinion at the sprints (right before I left) in the group discussion with Guido and Nick, but I'm not sure if it's been represented in this thread yet (I'm jetlagged and talk about Windows command prompts depresses me) -- so I'll just rehash it: distributing IDLE in the binary packages people download from python.org means *python-dev is still responsible IDLE*. We can't distribute something that we don't support. Even for the third-party libraries we're wrapping we're taking responsibility for updating them, fixing specific bugs or working around the bugs in the wrappers. Removing IDLE from the source tarballs isn't a way to disown it, or shed responsibility. The benefits of having IDLE in a separate repository, as I see it, would be that we can have separate access control for the repositories, and possibly make it more approachable for new developers, and easier to re-use by other Python implementations. We couldn't even sensibly stop accepting bugs for it on bugs.python.org. It may well be that moving IDLE to a separate repository is the right thing, but only if there's an active team of people working on it that would prefer it that way. And only if we realize that if IDLE languishes again, python-dev is *still* on the hook for it, even in the separate repository. I don't know if excluding it from the source tarball gains us anything on top of that -- although I do think we should move 'idlelib' out of the standard library :) -- Thomas Wouters Hi! I'm an email virus! Think twice before sending your email to help me spread!

On 3/21/2013 5:19 PM, Mark Janssen wrote:

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy mailto:tjreedy@udel.edu> wrote:

I might be jumping in late here, but...

Not at all. Thank you for the enlightening post.

The *only* thing I find "ugly" about it is that it doesn't have a white-on-black color scheme.

Oh. The wonderful thing about computers is the possibility of customizing to taste. The think I do not like about .pdf is the motivation to 'control the user experience'.

Look at any hacker console and you won't find a white screen. Otherwise its fine. Fixing that issue is simple, I can upload my color scheme if anyone wants.

If you want, open an IDLE enhancement issue "IDLE: add alternate high-light schemes", select Componemts: IDLE, and attach your 'Console' scheme. Many skinnable apps either have a place for users to share their custom skins or come with alternatives builtin. There might be other emulation schemes worth adding. -- Terry Jan Reedy