On Tue, Dec 23, 2014 at 9:29 PM, Kurt B. Kaiser <k...@shore.net> wrote: > > > On Tue, Dec 23, 2014, at 10:30 PM, Al Sweigart wrote: >> Hello, I'm Al Sweigart. I've joined the idle-dev list, but I can't >> seem to post to the list. I made an announcement about the "IDLE >> Reimagined" project, but I haven't received it from the list nor has >> it appeared in the archive on the web. Are my posts being held in >> moderation? Is there someone else I should talk to about the idle- >> dev list? >> >> Thanks for your time, > > Hi Al, > > I think that the reason your second message didn't make it was because > it is chock full of html. You may not be aware that posting to the > python lists should be done using plain text. >
Sorry about that, I've used a gmail-handled account to post to Pipermail lists before with the default settings and it didn't have an html/plaintext problem. I'll make sure my gmail messages to the list are explicitly set to plaintext in the future. > At least the second message didn't reference your ad-ridden wikia. > > Also, I apologize for the wikia link. I run ad-block on Chrome and Firefox, and didn't realize wikia had obnoxious ads until someone else pointed it out to me. I've since moved it to github's wiki. > Many people have designed Python IDEs. It seems that Scheme coders > write their own Scheme, and Python coders write their own IDEs. > > Lots of editors: > > https://wiki.python.org/moin/PythonEditors > > Lots of IDEs: > > https://wiki.python.org/moin/IntegratedDevelopmentEnvironments > > I think the "reimagined" in IDLE Reimagined might be giving the wrong idea. The changes I'd like to see wouldn't be a brand new from-scratch application, but using tkinter and the IDLE code base. (I know how we like to write code more than to modify it, and how the "rebuild it from scratch" often replaces the old set of bugs with a new set of bugs.) The redesign that I'd like to see would be to make design tradeoffs in favor of new programmers rather than regular developers. > In particular, there are many professional, complex IDEs. I remember > sitting through a PyCharm presentation at PyCon. The first question > was, essentially, "How do you turn all that stuff off?" > I completely agree with you. I don't want IDLE to be littered with features the way Eclipse or Gimp is. > IDLE is perfectly usable for "professional" development. I use it with > emacs for the C parts and command line for project and version control. > > It does what I want. (Up to the point where I ran out of time to work on > it.) It has its own niche, "non-complex, cross- platform IDEs". > > It's very important that a cross platform IDE be available out of the > box when Python is installed. The interactive interpreter in a shell > window doesn't cut it, especially on Windows. > I also see the fact that Python comes with a cross platform IDE as critical for the success of Python. I've always thought of the success of PHP was due to how easy it was to install. Lowering the barrier to entry is why I'd like to make changes to IDLE (tabs, single window instead of separate editor/interactive shell, i18n, etc.) > I read through your 2011 blog entry. It has a number of good ideas and > points out things that need fixing. Some have been. Some of your points > are just IDLE idiosyncrasies, like the End key jumping between the ends > of the line. I found that useful for selecting lines and changing > indentation; you might come to like it. (I see that isn't working in > 2.7.3, maybe someone "fixed" it...too bad.) > Reading back over the blog post, I'm not sure I know the particular End key issue you're talking about. (There's one about the Home key moving to the start of the >>> prompt instead the start of the line.) But I can see how a lot of design choices can have multiple opinions; I'm writing up the IDLE Reimagined design as a starting point for conversation, not as a conclusion. Everything about IR is up for negotiation. > Idiosyncrasy: The Python shell uses readline - the up arrow will move > history to the command line. In the IDLE shell, GvR didn't copy that, > but the up arrow key moves to the previous lines. If you hit most keys, > you get a beep, as you noticed. But if you hit enter, the *whole > expression* is copied to the command line, and it can be edited. That's > pretty cool. It is explained in the IDLE help, in the **TIPS**/Python > Shell section. Once shown, a kid will pick that up in a moment, with a > big smile. Saves a lot of typing when frobbing around. > I stumbled on this feature by accident. Like most users, I didn't read the help file. (Heh.) > I'm entirely in agreement that IDLE should be an IDE for beginners. > > If you want to re-imagine a beginner's cross-platform Python IDE, go for > it. But choose your own name if you are going to really tear it up, > please. > It's more important to fix the IDLE bugs and make it really solid for > beginners on all platforms, IMO. And avoid creeping features. > Feature-creep is something I definitely want to avoid. I've added a list of features that IR would explicitly *not* have, as way to set expectations of scope: https://github.com/asweigart/idle-reimagined/wiki/Why-Use-the-Existing-IDLE-Codebase%3F The major new features in the IR design would be the simplified real-time lint and post-to-pastebin feature. They're a lot of work, but I think they'll provide a huge payoff as well. But yeah, fixing bugs should take priority over implementing major features (which themselves will have new bugs). Currently I'm doing some design sketches, but mostly reading through the IDLE code base, reading through the idle-dev archive, and poking around on the Python issue tracker. Big, fancy features come after the simple improvements. > Guido had good reasons for his choices, I think. > > There was a long thread on python-dev awhile back, here's one post: > > https://mail.python.org/pipermail/python-dev/2013-March/124842.html > I read through the thread. Whether or not IDLE development is spun off into a separate project (I don't know enough about IDLE's development yet), I agree with GvR that IDLE should stay in the distribution. I don't mean to step on toes, and I understand how overly-idealistic it looks for an outsider to come in and express several ideas for changes at once. (And, again, none of the suggestions I make are intended to be deeply staked into the ground.) But I see a lot of potential for IDLE coming from a UI design and Python educator background as far as lowering the barrier to entry for new users. It'll probably be about mid-January before I broach this topic again. I was just poking to see if there was interest on the idle-dev list for people who wanted to take a look at the initial ideas. In the meantime, I'll be familiarizing myself with the IDLE code base and the issue tracker more. > -- > KBK > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > https://mail.python.org/mailman/listinfo/idle-dev _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
