From taleinat at gmail.com Thu Feb 1 23:22:51 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 2 Feb 2007 00:22:51 +0200 Subject: [Idle-dev] EditorWindow.set_close_hook Message-ID: <7afdee2f0702011422q4ec55b78rd1c493b082188252@mail.gmail.com> Hi all, I've recently checked out ways to have IDLE do something upon closing a window. Turns out the there is a beginning of such a mechanism in EditorWindow: the set_close_hook method. However, this method simply sets the instance's close_hook attribute, which means that setting it again will override the original hook. Specifically, EditorWindow sets the close_hook to FileList.close_edit(self), which removes the window from the FileList. This means that overriding the close_hook could (and would) cause bugs (in FileList)! The simplest solution AFAIK is to have a list of hooks and allow adding and removing hooks. Upon closing, the hooks are called in the reverse order of which they were added (i.e. last added is called first). Another solution would be to allow setting a new hook, and have a flag stating whether the old hook should be called after the new one is done. Obviously more comprehensive solutions exist but I don't think we need something more complex. Thoughts? Ideas? - Tal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070202/3808ef19/attachment.html From interstar at gmail.com Sun Feb 4 08:42:52 2007 From: interstar at gmail.com (phil jones) Date: Sun, 4 Feb 2007 05:42:52 -0200 Subject: [Idle-dev] hi, newbie questions Message-ID: Hi everyone, I just joined the list and wanted to say hello. My name's phil jones and I've been writing in Python for about 3 years and am still looking for the right editor / development environment for me to work with Python. I use IDLE about half the time I write Python. There are things I like about it and things that drive me crazy. Sometimes I dream about writing an IDE of my own or contributing to, or adapting an existing one. So I figured I should join the list. I have several questions : 1) the first is obviously, what's going on with IDLE? Couldn't find much documentation or discussion about it on the web (in terms of documentation or tutorials for people coding it), nor does it seem to have changed much over the last couple of releases of Python. How is it considered? An acceptable editor to get started, but serious Python programmers graduate to a "real IDE" (if so, which one?). The main *free* Python development environment? Or something which people here are planning to grow much further? How many people are actively involved in IDLE development at the moment? 2) The main thing that drives me crazy with IDLE and makes it pretty much unusuable for me is this. I like to develop with two files open, one with the code I'm working on and a second with unit tests. Obviously the unit-test file is the one I want to run and I import the other file into it. It seems like IDLE only does this import once, so that if I run the unit test, find a bug, fix the bug in the other file and re-run the unit tests (by hitting F5), IDLE doesn't notice that the code changed. So I then have to execute my program from the windows command line instead of hitting F5. Is this really how IDLE behaves? Or am I just doing something wrong / stpid and there's a way to get the behavior I want in IDLE? 3) One of the things I like about IDLE is that it's in Tk and standard in the Python distro, so you can be sure it's there. I've been developing a program with an editor-like GUI and I decided to use Tk / Tix rather than something based on another GUI layer, because of this. I thought I might be able to re-use bits of IDLE for it, and even contribute some stuff back to IDLE. However, when I upgraded to Python 2.5 my code just stopped working - with an error message saying that Python can't find and include Tix. Anyone know what's up with that? I thought Tix was part of standard Python? Did it break? Did IDLE also have problems with the upgrade to 2.5? 4) I'm guess I'm also looking for people here who know what's going on in with Tk, Tix and Tkinter. Tk is pretty basic, is it still being developed? Is there any work going on on Tix or any Python GUI frameworks which sit on top of Tk? Obviously there's GTk and wxPython and the OS native libraries which seem to be prefered by most Python projects. But I'm really interested in the "batteries-included" story for Python. cheers phil jones http://www.synaesmedia.net From bbands at gmail.com Wed Feb 7 21:34:46 2007 From: bbands at gmail.com (BBands) Date: Wed, 7 Feb 2007 12:34:46 -0800 Subject: [Idle-dev] IDLE suggestions Message-ID: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> You asked for some feature suggestions, so here goes. The ability to send code to the shell for execution. Send current line, send selection... (high priority) Use IPython as the shell. (medium priority) Tabbed documents. (medium priority) Projects, so that a group of related files would open at the same time. (medium priority) Code folding. (low priority) Automatic paren/bracket matching. (medium priority) Thanks for considering these ideas and thanks for IDLE, jab -- John Bollinger, CFA, CMT www.BollingerBands.com If you advance far enough, you arrive at the beginning. From michael at d2m.at Thu Feb 8 09:46:12 2007 From: michael at d2m.at (Michael Haubenwallner) Date: Thu, 08 Feb 2007 09:46:12 +0100 Subject: [Idle-dev] SearchBar - Have fun searching in IDLE! In-Reply-To: <7afdee2f0701290350i6a75606anb3fcf0cb8aefadc0@mail.gmail.com> References: <7afdee2f0701281540jc5a9fa3x176ec90f0f1631fb@mail.gmail.com> <45BDA8AF.5050306@d2m.at> <7afdee2f0701290350i6a75606anb3fcf0cb8aefadc0@mail.gmail.com> Message-ID: <45CAE354.6070907@d2m.at> Tal Einat wrote: > Thanks for the suggestions! Updated files attached. Thanks, works great now. On an aside: searching Google for idle extensions is not an easy thing. Do you know of a listing of available extensions or even a repository to download from ? If not, should there be one ? - wiki.python.org could have a page with a list of links - code.google.com/hosting could host such a repo How could we ease the process of installing an idle extension ? I see no problem to just make the extension a package and put it in the python path (site-packages). Then we would need to change idlelib.configHandler.IdleConf to accept the package path besides the idleDir and userDir config options. This lets us eggify an extension and use ez_install for download and installation. Your comments are welcome. Michael -- http://zope.org/Members/d2m http://planetzope.org From taleinat at gmail.com Thu Feb 8 10:20:46 2007 From: taleinat at gmail.com (Tal Einat) Date: Thu, 8 Feb 2007 11:20:46 +0200 Subject: [Idle-dev] SearchBar - Have fun searching in IDLE! In-Reply-To: <45CAE354.6070907@d2m.at> References: <7afdee2f0701281540jc5a9fa3x176ec90f0f1631fb@mail.gmail.com> <45BDA8AF.5050306@d2m.at> <7afdee2f0701290350i6a75606anb3fcf0cb8aefadc0@mail.gmail.com> <45CAE354.6070907@d2m.at> Message-ID: <7afdee2f0702080120u10db95d3s3da56f903f2b3081@mail.gmail.com> On 2/8/07, Michael Haubenwallner wrote: > > On an aside: searching Google for idle extensions is not an easy thing. > > Do you know of a listing of available extensions or even a repository to > download from ? AFAIK there is none. > If not, should there be one ? > - wiki.python.org could have a page with a list of links > - code.google.com/hosting could host such a repo I believe there should be one, once the selection is sizeable (as it is starting to become) and installation ease is improved... > How could we ease the process of installing an idle extension ? > I see no problem to just make the extension a package and put it in the > python path (site-packages). > Then we would need to change idlelib.configHandler.IdleConf to accept > the package path besides the idleDir and userDir config options. > This lets us eggify an extension and use ez_install for download and > installation. This is a very good idea! A few points which need to be resolved first: 1. Even if we could get idleConf to work like this, we would still need a way for IDLE to know about extensions. Currently extensions are "registered" by them adding an entry in config-extensions. How would we do this otherwise? 2. Currently user config is in a single config-extensions file. How would we manage user configuration with each extension being a separate module? Regarding #2, I think we could still have user config in a single config-extensions file, where config for all extensions is stored. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070208/9628032a/attachment.html From ronaldoussoren at mac.com Thu Feb 8 10:35:29 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 8 Feb 2007 10:35:29 +0100 Subject: [Idle-dev] SearchBar - Have fun searching in IDLE! In-Reply-To: <7afdee2f0702080120u10db95d3s3da56f903f2b3081@mail.gmail.com> References: <7afdee2f0701281540jc5a9fa3x176ec90f0f1631fb@mail.gmail.com> <45BDA8AF.5050306@d2m.at> <7afdee2f0701290350i6a75606anb3fcf0cb8aefadc0@mail.gmail.com> <45CAE354.6070907@d2m.at> <7afdee2f0702080120u10db95d3s3da56f903f2b3081@mail.gmail.com> Message-ID: On 8 Feb, 2007, at 10:20, Tal Einat wrote: > On 2/8/07, Michael Haubenwallner wrote: > > On an aside: searching Google for idle extensions is not an easy > thing. > > Do you know of a listing of available extensions or even a > repository to > download from ? > > AFAIK there is none. > > > If not, should there be one ? > - wiki.python.org could have a page with a list of links > - code.google.com/hosting could host such a repo > > I believe there should be one, once the selection is sizeable (as > it is starting to become) and installation ease is improved... The cheeseshop is another option and is used by a number of the web frameworks. If you ask nicely the cheeseshop maintainer could even add a classifier/category for IDLE extensions. > > > How could we ease the process of installing an idle extension ? > I see no problem to just make the extension a package and put it in > the > python path (site-packages). > Then we would need to change idlelib.configHandler.IdleConf to accept > the package path besides the idleDir and userDir config options. > This lets us eggify an extension and use ez_install for download and > installation. > > This is a very good idea! A few points which need to be resolved > first: > Even if we could get idleConf to work like this, we would still > need a way for IDLE to know about extensions. Currently extensions > are "registered" by them adding an entry in config-extensions. How > would we do this otherwise? Setuptools entry-points are one option for this. Another option is installing all plugins in a special magic pacage and load all modules in that package. > Currently user config is in a single config-extensions file. How > would we manage user configuration with each extension being a > separate module? > Regarding #2, I think we could still have user config in a single > config-extensions file, where config for all extensions is stored > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070208/b57059d3/attachment.htm From taleinat at gmail.com Thu Feb 8 11:41:10 2007 From: taleinat at gmail.com (Tal Einat) Date: Thu, 8 Feb 2007 12:41:10 +0200 Subject: [Idle-dev] IDLE suggestions In-Reply-To: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> References: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> Message-ID: <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> On 2/7/07, BBands wrote: > > You asked for some feature suggestions, so here goes. > > The ability to send code to the shell for execution. Send current > line, send selection... (high priority) For a line or selection - what is the great benefit over a simple copy + paste? The only thing I can think of is removing empty lines, which is required whenever pasting into the interpreter. Such an option for IDLE's shell - removing blank lines (and perhaps also prompt characters) from pasted code - would be useful. Thinking about this some more, there is also an issue with tabs/spaces when copying code between the shell and editor windows. This has recently been mentioned in the new ShowMeDo video on IDLE (in the latest Python For Newbies series). This could be solved by converting tabs/spaces as appropriate upon pasting of code. The question is how to add this functionality in the least confusing manner. I don't think these things should happen automagically upon a normal paste. Perhaps a separate "paste code" option in the Edit menu? Use IPython as the shell. (medium priority) Hmm, this is an interesting suggestion. I've heard the rave about IPython but haven't gotten to using it yet. I'm not sure how easy (or possible) such integration would be, since IPython is textual, and we would need to wrap GUI around it. On the other hand, the developers say it's intended for integration into Python programs. Also I'm wary about such a step. IDLE is the easy to use and learn because it doesn't pack on tons of complex features. IPython is said to be very feature rich - I'm not sure if we want to use such a complex interpreter, since it could confuse new users. Tabbed documents. (medium priority) Work on this is under way. Projects, so that a group of related files would open at the same > time. (medium priority) I think we're currently against this - too complicated for new users! I could see this added to IDLE only in addition to its current edit-one-file functionality, and not as the default behavior. I'd really hate to see an IDLE tutorial beginning with "First of all let's start a project...", since all IDLE tutorials should start with "Ok, here's the interpreter, let's play around!" :) Seeing how this would be a difficult feature to implement, I think some more interest in such a feature is required before it's considered. I haven't heard this as a major feature request from most IDLE users. Code folding. (low priority) Though I know some IDLEers are against this, I think this is a good idea for an extension. I'm thinking of making such an extension, based on the Squeezer extension, using Tk text widget tags with the "elide" tag to hide text. The only really tricky part I can think of is integrating this nicely with the search, which would have to be able to search (or not) inside folded code, and show the results. This would seem to require automatic unfolding/refolding of code. How is this done in other IDEs which support code folding? Automatic paren/bracket matching. (medium priority) This is already implemented in the ParenMatch extension - or do you mean something else? Thanks for the suggestions! - Tal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070208/5155fa73/attachment.html From fuzzyman at voidspace.org.uk Thu Feb 8 12:04:19 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 08 Feb 2007 11:04:19 +0000 Subject: [Idle-dev] SearchBar - Have fun searching in IDLE! In-Reply-To: References: <7afdee2f0701281540jc5a9fa3x176ec90f0f1631fb@mail.gmail.com> <45BDA8AF.5050306@d2m.at> <7afdee2f0701290350i6a75606anb3fcf0cb8aefadc0@mail.gmail.com> <45CAE354.6070907@d2m.at> <7afdee2f0702080120u10db95d3s3da56f903f2b3081@mail.gmail.com> Message-ID: <45CB03B3.3090902@voidspace.org.uk> Ronald Oussoren wrote: > [snip..] > >> >> >> >> How could we ease the process of installing an idle extension ? >> I see no problem to just make the extension a package and put it >> in the >> python path (site-packages). >> Then we would need to change idlelib.configHandler.IdleConf to accept >> the package path besides the idleDir and userDir config options. >> This lets us eggify an extension and use ez_install for download and >> installation. >> >> >> This is a very good idea! A few points which need to be resolved first: >> >> 1. Even if we could get idleConf to work like this, we would still >> need a way for IDLE to know about extensions. Currently >> extensions are "registered" by them adding an entry in >> config-extensions. How would we do this otherwise? >> > > Setuptools entry-points are one option for this. Another option is > installing all plugins in a special magic pacage and load all modules > in that package. That's the approach we use for Firedrop. There is still a config file to edit to enable extensions. You might not want all available extensions available by default unless you are going to provide a GUI for enabling / disabling. (Requiring a restart after changing these options would be fine I guess.) Fuzzyman http://www.voidspace.org.uk/python/articles.shtml >> 1. >> >> >> 2. Currently user config is in a single config-extensions file. >> How would we manage user configuration with each extension >> being a separate module? >> >> Regarding #2, I think we could still have user config in a single >> config-extensions file, where config for all extensions is stored >> >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev > > ------------------------------------------------------------------------ > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > From taleinat at gmail.com Thu Feb 8 15:48:13 2007 From: taleinat at gmail.com (Tal Einat) Date: Thu, 8 Feb 2007 16:48:13 +0200 Subject: [Idle-dev] hi, newbie questions In-Reply-To: References: Message-ID: <7afdee2f0702080648g6b85754ek77602f6c6e579fd6@mail.gmail.com> On 2/4/07, phil jones wrote: > > Hi everyone, > > I just joined the list and wanted to say hello. > > My name's phil jones and I've been writing in Python for about 3 years > and am still looking for the right editor / development environment > for me to work with Python. I use IDLE about half the time I write > Python. There are things I like about it and things that drive me > crazy. Sometimes I dream about writing an IDE of my own or > contributing to, or adapting an existing one. So I figured I should > join the list. Great! Welcome! I have several questions : > > 1) the first is obviously, what's going on with IDLE? Couldn't find > much documentation or discussion about it on the web (in terms of > documentation or tutorials for people coding it), nor does it seem to > have changed much over the last couple of releases of Python. How is > it considered? An acceptable editor to get started, but serious Python > programmers graduate to a "real IDE" (if so, which one?). The main > *free* Python development environment? Or something which people here > are planning to grow much further? How many people are actively > involved in IDLE development at the moment? I think the general perception of IDLE is pretty much your first guess - a simple IDE, easy to learn so good for starters, serious coder later embrace more complex/comprehensive/feature-rich IDEs. I wouldn't say it's the main free Python IDE, with SPE, PyDev and others to be found. I also wouldn't say that it's something which is planned to grow much further, unfortunately. I think there's still a lot to do, since IDLE is not as good starting point for beginners as it could be - too many ugly bumps, an incomplete debugging module, and missing basic features neing the reasons. In my opinion, which I have been trying to "push" for the past two years, IDLE is an awesome Python shell, which comes with a nice, simple editor, which integrates well with the shell. It's definitely great for learning and teaching Python, but IMO it's good for much more than that. 2) The main thing that drives me crazy with IDLE and makes it pretty > much unusuable for me is this. I like to develop with two files open, > one with the code I'm working on and a second with unit tests. > Obviously the unit-test file is the one I want to run and I import the > other file into it. It seems like IDLE only does this import once, so > that if I run the unit test, find a bug, fix the bug in the other file > and re-run the unit tests (by hitting F5), IDLE doesn't notice that > the code changed. So I then have to execute my program from the > windows command line instead of hitting F5. > > Is this really how IDLE behaves? Or am I just doing something wrong / > stpid and there's a way to get the behavior I want in IDLE? You're not doing much wrong - this is one of the "ugly bumps" I mentioned earlier. You're running IDLE without a subprocess - if you would run IDLE with a subprocess, this issue would be resolved. (it would work since the shell would be restarted each time you hit F5) If you run IDLE from the Start Menu on Windows, or run it without the -n flag on Unix/Linux/..., IDLE will run with a subprocess. On the other hand, when you use "Edit with IDLE" from the Windows Explorer context menu, or run IDLE with the -n flag, IDLE runs without a subprocess, and so the shell cannot be restarted. I have a patch which will finally resolve this issue posted on SourceForge, but it's not getting enough attention... I'm hoping to get it into Python2.6though. 3) One of the things I like about IDLE is that it's in Tk and standard > in the Python distro, so you can be sure it's there. I've been > developing a program with an editor-like GUI and I decided to use Tk / > Tix rather than something based on another GUI layer, because of this. > I thought I might be able to re-use bits of IDLE for it, and even > contribute some stuff back to IDLE. However, when I upgraded to Python > 2.5 my code just stopped working - with an error message saying that > Python can't find and include Tix. Anyone know what's up with that? I > thought Tix was part of standard Python? Did it break? Did IDLE also > have problems with the upgrade to 2.5? IDLE had no problems with the upgrade to 2.5. Perhaps this is because IDLE uses only Tkinter, no Tix. Sorry, I don't know much about Tix... 4) I'm guess I'm also looking for people here who know what's going on > in with Tk, Tix and Tkinter. Tk is pretty basic, is it still being > developed? Is there any work going on on Tix or any Python GUI > frameworks which sit on top of Tk? Hasn't been under serious development for years, but maybe there's some hope left for it yet... Check out Tcl/Tk's website: http://www.tcl.tk/ Also check out the Tile project, which aims to allow Tk GUI to look like most common GUI frameworks (Windows classic and WinXP to name a few) Obviously there's GTk and wxPython and the OS native libraries which > seem to be prefered by most Python projects. But I'm really interested > in the "batteries-included" story for Python. cheers > > phil jones > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070208/4401ee75/attachment.html From bbands at gmail.com Thu Feb 8 19:40:55 2007 From: bbands at gmail.com (BBands) Date: Thu, 8 Feb 2007 10:40:55 -0800 Subject: [Idle-dev] IDLE suggestions In-Reply-To: <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> References: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> Message-ID: <6e8360ad0702081040s4af06330jcc4a9b089e85602d@mail.gmail.com> Tal and IDLErs, Upon reflection I completely agree with the philosophy of keeping IDLE simple and easy for newbes to use. So, in reply to Tal's replies: I have had trouble with cut and paste to the shell where I wanted to paste a function or multiple lines. If your paste code idea allows that, it will be good for me. (I don't use tabs in Python.) IPyhton is really neat, but in keeping with the keep-it-simple idea perhaps you should forget or backburner this idea. Let me know when it's ready and I'll help test tabbed docs. Instead of projects might save/restore a workspace be an idea? Code folding would be nice, an alternative for IDLE might be something like what Mark Hammond implemented in PythonWin, two views on the same file via a movable horizontal bar. As for paren matching, as of Python 2.5, IDLE 1.2 it is not working as I would expect on xp. For example, I would expect the pair of parens/brackets to change color when the cursor hits one. Right now the first one or two of panen completions get greyed, after that nothing else happens though ctrl-0 works. If you let me know how it is intended to work I'll test it and post a field report. Thanks for all you work on IDLE, jab -- John Bollinger, CFA, CMT www.BollingerBands.com If you advance far enough, you arrive at the beginning. From taleinat at gmail.com Fri Feb 9 01:23:57 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 9 Feb 2007 02:23:57 +0200 Subject: [Idle-dev] Friendlier pasting of code Message-ID: <7afdee2f0702081623m6ce7545as86baeae8ce2f5232@mail.gmail.com> To follow up the suggestion by John Bollinger regarding moving code between editor and shell windows: I've written up an initial patch for IDLE which adds a Paste Code item in the Edit menu (and a Control+Shift+V hotkey for it). Selecting this option pastes the code from the clipboard, but with adjustments: * Remove prompt characters (currently ">>> " or "... ", to also support code from a command-line Python shell) * When pasting to a shell, remove empty lines (i.e. all whitespace characters) These adjustments are applied only to lines of code (multi-line strings are not changed). Attached is unified diff to the current idlelib SVN (rev. 53679). Please take a moment to install and test this, report comments and bugs, and tell me what you think. If you like it, I'll post the patch in SourceForge. Enjoy! - Tal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070209/ebaaa89e/attachment.htm From taleinat at gmail.com Fri Feb 9 01:36:49 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 9 Feb 2007 02:36:49 +0200 Subject: [Idle-dev] IDLE suggestions In-Reply-To: <6e8360ad0702081040s4af06330jcc4a9b089e85602d@mail.gmail.com> References: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> <6e8360ad0702081040s4af06330jcc4a9b089e85602d@mail.gmail.com> Message-ID: <7afdee2f0702081636r833551avb15c6529483a977@mail.gmail.com> On 2/8/07, BBands wrote: > So, in reply to Tal's replies: > > I have had trouble with cut and paste to the shell where I wanted to > paste a function or multiple lines. If your paste code idea allows > that, it will be good for me. (I don't use tabs in Python.) See initial implementation in separate mail :D Instead of projects might save/restore a workspace be an idea? That's an nice idea, sounds good to me. As for paren matching, as of Python 2.5, IDLE 1.2 it is not working as > I would expect on xp. For example, I would expect the pair of > parens/brackets to change color when the cursor hits one. Right now > the first one or two of panen completions get greyed, after that > nothing else happens though ctrl-0 works. If you let me know how it is > intended to work I'll test it and post a field report. Well, sounds like it's working just fine. Currently IDLE doesn't flash matching parens every time the cursor hits one. I've seen other IDEs do this, and it is somewhat useful, mostly to catch unbalanced parens early. I'd like to hear some opinions on this - which behavior is preferred? Having matching parens highlight whenever the cursor is on one, or only when typed or Ctrl- is hit? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070209/9b4e2790/attachment-0001.html From fuzzyman at voidspace.org.uk Fri Feb 9 01:46:03 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 09 Feb 2007 00:46:03 +0000 Subject: [Idle-dev] IDLE suggestions In-Reply-To: <7afdee2f0702081636r833551avb15c6529483a977@mail.gmail.com> References: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> <6e8360ad0702081040s4af06330jcc4a9b089e85602d@mail.gmail.com> <7afdee2f0702081636r833551avb15c6529483a977@mail.gmail.com> Message-ID: <45CBC44B.3000403@voidspace.org.uk> Tal Einat wrote: > On 2/8/07, *BBands* > wrote: > > So, in reply to Tal's replies: > > I have had trouble with cut and paste to the shell where I wanted to > paste a function or multiple lines. If your paste code idea allows > that, it will be good for me. (I don't use tabs in Python.) > > > See initial implementation in separate mail :D > > Instead of projects might save/restore a workspace be an idea? > > > That's an nice idea, sounds good to me. > > As for paren matching, as of Python 2.5, IDLE 1.2 it is not working as > I would expect on xp. For example, I would expect the pair of > parens/brackets to change color when the cursor hits one. Right now > the first one or two of panen completions get greyed, after that > nothing else happens though ctrl-0 works. If you let me know how it is > intended to work I'll test it and post a field report. > > > Well, sounds like it's working just fine. Currently IDLE doesn't flash > matching parens every time the cursor hits one. I've seen other IDEs > do this, and it is somewhat useful, mostly to catch unbalanced parens > early. > > I'd like to hear some opinions on this - which behavior is preferred? > Having matching parens highlight whenever the cursor is on one, or > only when typed or Ctrl- is hit? If the coloring is subtle I prefer automatic highlighting. It makes it easier when you are stepping through nested expressions to have the parens highlighted automatically... Fuzzyman http://www.voidspace.org.uk/python/articles.shtml > ------------------------------------------------------------------------ > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.411 / Virus Database: 268.17.30/674 - Release Date: 07/02/2007 > > From interstar at gmail.com Fri Feb 9 05:52:01 2007 From: interstar at gmail.com (phil jones) Date: Fri, 9 Feb 2007 01:52:01 -0300 Subject: [Idle-dev] Fwd: hi, newbie questions In-Reply-To: References: <7afdee2f0702080648g6b85754ek77602f6c6e579fd6@mail.gmail.com> Message-ID: Hi Tal, thanks for the replies. I think I misread your mail the first couple of times. Am I right in interpreting you as saying that in general people don't see IDLE being developed into anything "grander" but you personally disagree? In which case, I assume the community are not against people trying to re-use parts of IDLE in their own editors. Is there any tutorial documentation explaining how IDLE is put together, and showing how to extend it? I know there was something called IDEStudio that tried to incorporate IDLE in a full IDE, but that seems to have vanished. Is it dead? Was any documentation generated because of that? Also, how intertwingled with Tk *is* IDLE. Would it be big or small job to port it to a different GUI? Is there a good Model-View-Controller separation? Also, where do you personally want to take IDLE? > In my opinion, which I have been trying to "push" for the past two years, > IDLE is an awesome Python shell, which comes with a nice, simple editor, > which integrates well with the shell. It's definitely great for learning and > teaching Python, but IMO it's good for much more than that. Yeah, seems like it shouldn't be that difficult to make more of it. And I think being bundled with Python is a great opportunity. Python is a language I really like; but like everyone I've been impressed how Ruby has been riding high on the wave of Rails. It makes you realize how important good tools and frameworks are. Seems like Python lost a bit of momentum both in web-server space and for desktop applications. I like some of the thinking behind PythonCard, although that seems to be going pretty slowly too. Python should be a great learning, scripting, whip-up-a-desktop-app. language to do the things Visual Basic does. But the lack of a good development environment seems to be holding it back. I'm sure fragmentation between Tk and wxPython is part of that. I'm not saying I'm looking for a VB *clone*. But it would be nice to have something out-of-the-original-box that's comfortable to just go with and start building apps. > > 2) The main thing that drives me crazy with IDLE and makes it pretty > > much unusuable for me is this. I like to develop with two files open, > > one with the code I'm working on and a second with unit tests. > > Obviously the unit-test file is the one I want to run and I import the > > other file into it. It seems like IDLE only does this import once, so > > that if I run the unit test, find a bug, fix the bug in the other file > > and re-run the unit tests (by hitting F5), IDLE doesn't notice that > > the code changed. So I then have to execute my program from the > > windows command line instead of hitting F5. > > > > Is this really how IDLE behaves? Or am I just doing something wrong / > > stpid and there's a way to get the behavior I want in IDLE? > > You're not doing much wrong - this is one of the "ugly bumps" I mentioned > earlier. You're running IDLE without a subprocess - if you would run IDLE > with a subprocess, this issue would be resolved. (it would work since the > shell would be restarted each time you hit F5) > > If you run IDLE from the Start Menu on Windows, or run it without the -n > flag on Unix/Linux/..., IDLE will run with a subprocess. On the other hand, > when you use "Edit with IDLE" from the Windows Explorer context menu, or run > IDLE with the -n flag, IDLE runs without a subprocess, and so the shell > cannot be restarted. > I have a patch which will finally resolve this issue posted on SourceForge, > but it's not getting enough attention... I'm hoping to get it into Python2.6 > though. Thanks. That makes sense and I think I can live with the workaround. But looking forward to the patch. > Is there any work going on on Tix or any Python GUI > > frameworks which sit on top of Tk? > > Hasn't been under serious development for years, but maybe there's some hope > left for it yet... > > Check out Tcl/Tk's website: http://www.tcl.tk/ I had a look but didn't see anything interesting. I used to use Tcl quite a lot at work, but can't see any reason these days that I'd choose it over Python. I wonder why Perl / Python / Ruby have let themselves be so dependent on Tk. I wonder if there's any move to create a new common toolkit on top of something else (eg. Gtk or wxWindows) and have *it* as standard in things like Python and Ruby. Perhaps it would be possible to even make Python's Tkinter wrap this new library directly so as not to break existing code? > Also check out the Tile project, which aims to allow Tk GUI to look like > most common GUI frameworks (Windows classic and WinXP to name a few) Looks interesting ... Actually something else which I see on the horizon and may prove interesting is the work going on to get Python talking with Gecko / XUL ( http://developer.mozilla.org/en/docs/My_Chrome_Oven:_Generating_XUL_with_Python) Anyone know anything about that? Perhaps the right way to go is to build desktop apps. on top of Gecko and help yourself to XUL / HTML / CSS for the UI components. I heard that Komodo is built that way? Anyway thanks for all the useful info. and for listening :-) phil jones From broek at cc.umanitoba.ca Fri Feb 9 10:42:26 2007 From: broek at cc.umanitoba.ca (Brian van den Broek) Date: Fri, 09 Feb 2007 03:42:26 -0600 Subject: [Idle-dev] IDLE suggestions In-Reply-To: <45CBC44B.3000403@voidspace.org.uk> References: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> <6e8360ad0702081040s4af06330jcc4a9b089e85602d@mail.gmail.com> <7afdee2f0702081636r833551avb15c6529483a977@mail.gmail.com> <45CBC44B.3000403@voidspace.org.uk> Message-ID: <45CC4202.1040301@cc.umanitoba.ca> Michael Foord said unto the world upon 02/08/2007 06:46 PM: > Tal Einat wrote: >> On 2/8/07, *BBands* > wrote: >> As for paren matching, as of Python 2.5, IDLE 1.2 it is not working as >> I would expect on xp. For example, I would expect the pair of >> parens/brackets to change color when the cursor hits one. Right now >> the first one or two of panen completions get greyed, after that >> nothing else happens though ctrl-0 works. If you let me know how it is >> intended to work I'll test it and post a field report. >> >> >> Well, sounds like it's working just fine. Currently IDLE doesn't flash >> matching parens every time the cursor hits one. I've seen other IDEs >> do this, and it is somewhat useful, mostly to catch unbalanced parens >> early. >> >> I'd like to hear some opinions on this - which behavior is preferred? >> Having matching parens highlight whenever the cursor is on one, or >> only when typed or Ctrl- is hit? > If the coloring is subtle I prefer automatic highlighting. > > It makes it easier when you are stepping through nested expressions to > have the parens highlighted automatically... > > Fuzzyman +1 Brian vdB From taleinat at gmail.com Fri Feb 9 12:40:21 2007 From: taleinat at gmail.com (Tal Einat) Date: Fri, 9 Feb 2007 13:40:21 +0200 Subject: [Idle-dev] Friendlier pasting of code In-Reply-To: <7afdee2f0702081623m6ce7545as86baeae8ce2f5232@mail.gmail.com> References: <7afdee2f0702081623m6ce7545as86baeae8ce2f5232@mail.gmail.com> Message-ID: <7afdee2f0702090340p47ca3efm27e5f9a2294f9ff6@mail.gmail.com> Sorry, Gmail seems to have barfed my attachment. I'm attaching the patch again, hopefully it will work this time! On 2/9/07, Tal Einat wrote: > > To follow up the suggestion by John Bollinger regarding moving code > between editor and shell windows: > > I've written up an initial patch for IDLE which adds a Paste Code item in > the Edit menu (and a Control+Shift+V hotkey for it). > > Selecting this option pastes the code from the clipboard, but with > adjustments: > * Remove prompt characters (currently ">>> " or "... ", to also support > code from a command-line Python shell) > * When pasting to a shell, remove empty lines (i.e. all whitespace > characters) > > These adjustments are applied only to lines of code (multi-line strings > are not changed). > > > Attached is unified diff to the current idlelib SVN (rev. 53679). > > Please take a moment to install and test this, report comments and bugs, > and tell me what you think. > If you like it, I'll post the patch in SourceForge. > > Enjoy! > - Tal > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/idle-dev/attachments/20070209/e2022e08/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: IDLE_paste_code.070209.patch Type: application/octet-stream Size: 4503 bytes Desc: not available Url : http://mail.python.org/pipermail/idle-dev/attachments/20070209/e2022e08/attachment.obj From interstar at gmail.com Fri Feb 9 16:57:00 2007 From: interstar at gmail.com (phil jones) Date: Fri, 9 Feb 2007 12:57:00 -0300 Subject: [Idle-dev] hi, newbie questions In-Reply-To: <7afdee2f0702090333h28951718v32e97cdb1e8be3ed@mail.gmail.com> References: <7afdee2f0702080648g6b85754ek77602f6c6e579fd6@mail.gmail.com> <7afdee2f0702090333h28951718v32e97cdb1e8be3ed@mail.gmail.com> Message-ID: On 2/9/07, Tal Einat wrote: > Not quite - sorry to have been vague. I think IDLE should -NOT- be a > full-blown complex IDE, with support for such things as version control and > projects. OK, gotcha > I do think IDLE could be far better at what it is meant to be - a good > interpreter with a nice editor, simple to learn but powerful enough to use. > You might say that this is more-or-less how Python is often described, which > is precisely why IDLE should be that way too. > > Is there any tutorial > > documentation explaining how IDLE is put together, and showing how to > > extend it? > > Not that I know of. The code itself is also quite poorly documented in many > places. I noticed :-) > (There is a short guide to writing IDLE extensions ( i.e. plug-ins), but > that's not what you meant...) > What's MVC again? ;) > > IDLE is very, very dependent on Tk, especially on the event binding > mechanism and on the workings of the Text widget. MVC was not used when > writing IDLE. OK. > I don't want to take IDLE to new places. Like I said - I want it to be a > truly awesome Python shell, with a usable editor, easy to learn and use for > newbies. Perhaps in the future I'll try to make a variant with a more > powerful shell, or a new shell altogether - but that's for the future. What do you think of PyCrust etc? Do you think the shell should be more like these? > > Yeah, seems like it shouldn't be that difficult to make more of it. > > And I think being bundled with Python is a great opportunity. > > Mostly, I mean IDLE being a great Python shell, with potential to be greater > being built with a GUI toolkit (unlike IPython), and being 100% > cross-platform. re: fragmentation > You could say the same about Linux and the much larger fragmentation there. > But fragmentation is natural, and the selective forces in the Open Source > world are much weaker, so the fragments take a long time to die out / merge > together. The free Python IDEs just don't have enough of a driving force > behind them. yep, and OK, I grant that pluralism is a good thing > One reason for this, worth pointing out, is that people don't know what's > good for them. Programmers don't know what to ask for in a good IDE. And > even worse, some experienced programmers do know what's good for them - and > it's vastly different for each one. Outcome - you don't get a strong driving > force behind a single IDE. yes. > I think WingIDE is in the right direction, it's supposed to be very good - > but it's not open-source and costs money, which is a problem for most > Pythoneers. But I think making a really, really good Python IDE, which costs > a bit of money, is a good way to get the resources needed to build a good > IDE. suppose so. I tried WingIDE demo and didn't like it all that much. I prefer Stani's - and not just because it's free. My issue with plurality is not *choosing* what I want. It's installing and managing. I use four different PCs in different places, and carry the source-code around for my projects on a pen-drive. I want to stick as much as possible with out-of-the-box python because having to install and upgrade various external libraries on multiple machines gets boring pretty quickly. And especially as my laptop is not always connected to the net, > As for Rails, it makes me understand how important popularity and "buzz" is. > Popular frameworks gain momentum quickly since there is more support for > them, more job opportunities for someone who knows them, more potential > employees for a company with a product based on them, etc. Not necessarily > because they get the job done better/faster than the alternatives. Sure. My point was not that Ruby or Rails is cool. My point was that having a development framework that lets you get on and produce stuff quickly is a great attraction, and if you pull in a larger community, more people drive things forward faster. BTW : never really used Ruby, but one thing that impressed me a couple of years ago was how I managed to download and install Instiki (a Ruby wiki) on my office intranet very easily because of the Gems thing. Python Eggs seems like it should make searching and managing other packages easier. But I don't see any support for them in IDLE. Do you think this kind of thing : eg. a menu option for downloading and installing eggs via IDLE is considered outside the scope of what a tool like IDLE should provide? > Yea, it would, wouldn't it? They way it is now, you actually have to decide > for yourself what's best for -your- needs, and everyone hates that! *wink* (See above ... also, I want to make software for people who don't, themselves, know how to download the appropriate supporting libraries and packages) > I do agree that there aren't good and easy enough tools for developing > desktop applications with Python right now. Heck, it's what I've been doing > for the past 2 months, and I can say that wxGlade doesn't meet the grade. > This really is why there are so few apps written in Python, compared to VB. But Python had such *potential* here ... :-( Tkinter wrapping other lib. > I don't think so - Tkinter is a thin wrapper around Tk. There is no way to > wrap wxWidgets, for example, with a Tkinter-like API. Ah well > I think wxPython is slowly gaining momentum, with the lack of a WYSIWYG GUI > builder holding it back. As it is, wxPython is great if you like to write > your GUI by hand. But I don't see it entering the main CPython distribution > any time soon. Any reason why not? Too heavy? Political reasons? Too much investment in Tk? > What I think is more plausible than having wxPython distributed with > vanilla-CPython, is that someone will create a Python distro that comes with > a GUI toolkit (e.g. wxPython) and a sound application development > environment. yeah, some kind of one-stop solution would be nice. phil From sspatz at kcnet.com Fri Feb 9 18:30:33 2007 From: sspatz at kcnet.com (Saul Spatz) Date: Fri, 09 Feb 2007 11:30:33 -0600 Subject: [Idle-dev] IDLE suggestions In-Reply-To: <45CBC44B.3000403@voidspace.org.uk> References: <6e8360ad0702071234i7094823elff4ecaf886dbb991@mail.gmail.com> <7afdee2f0702080241q4ed3e07w689e0fb913ef1f76@mail.gmail.com> <6e8360ad0702081040s4af06330jcc4a9b089e85602d@mail.gmail.com> <7afdee2f0702081636r833551avb15c6529483a977@mail.gmail.com> <45CBC44B.3000403@voidspace.org.uk> Message-ID: <45CCAFB9.5060103@kcnet.com> Michael Foord wrote: > Tal Einat wrote: > >> On 2/8/07, *BBands* > wrote: >> >> So, in reply to Tal's replies: >> >> I have had trouble with cut and paste to the shell where I wanted to >> paste a function or multiple lines. If your paste code idea allows >> that, it will be good for me. (I don't use tabs in Python.) >> >> >> See initial implementation in separate mail :D >> >> Instead of projects might save/restore a workspace be an idea? >> >> >> For me, projects are really essential for serious development. However, for getting started, or for teaching, I think doing without projects is best. Some free ware C++ IDE's support projects, but also allow you compile and link a single file without making a project. This is the ideal approach, IMO. >> That's an nice idea, sounds good to me. >> >> As for paren matching, as of Python 2.5, IDLE 1.2 it is not working as >> I would expect on xp. For example, I would expect the pair of >> parens/brackets to change color when the cursor hits one. Right now >> the first one or two of panen completions get greyed, after that >> nothing else happens though ctrl-0 works. If you let me know how it is >> intended to work I'll test it and post a field report. >> >> >> Well, sounds like it's working just fine. Currently IDLE doesn't flash >> matching parens every time the cursor hits one. I've seen other IDEs >> do this, and it is somewhat useful, mostly to catch unbalanced parens >> early. >> >> I'd like to hear some opinions on this - which behavior is preferred? >> Having matching parens highlight whenever the cursor is on one, or >> only when typed or Ctrl- is hit? >> > If the coloring is subtle I prefer automatic highlighting. > > It makes it easier when you are stepping through nested expressions to > have the parens highlighted automatically... > > I agree with this. I like the way the coloring works now, but I would prefer having only the matching parentheses flash when the cursor hits one, without graying all the intervening text. If the user can choose the foreground/background colors for the matching, he can get coloring as subtle or garish as he wants. > Fuzzyman > http://www.voidspace.org.uk/python/articles.shtml > > >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev >> >> ------------------------------------------------------------------------ >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.411 / Virus Database: 268.17.30/674 - Release Date: 07/02/2007 >> >> >> > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > > > Saul Spatz