From tjreedy at udel.edu Thu Nov 5 02:42:21 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 5 Nov 2015 02:42:21 -0500 Subject: [Idle-dev] Upcoming releases Message-ID: Both 2.7.11c1 and 3.5.1c1 are scheduled to be tagged at some time on Nov. 21. Being tagged means that no more commits go into the release candidates, while they are being prepared for the actual release the next day. I don't expect to put any major changes in before that, but there are several little issues to finish, and I prefer to get things in at least a day before the tagging. 2.7.11 and 3.5.1 are scheduled for Dec 5/6. I expect that no IDLE commits will be needed for those. 3.4.4c1 is scheduled for the same weekend. Its possible I won't commit anything to 3.4.4 after Nov 21, especially not during the Thanksgiving weekend. After that, it would normally be 4-6 months until 3.5.2. 3.6.0a1 is scheduled for mid-May 2016. 2.7.12 should be about the same or later. I hope we can have at least a basic complete ttk version for all three of these releases. I want to seriously start that in early December. -- Terry Jan Reedy From alan.gauld at btinternet.com Sat Nov 7 07:53:25 2015 From: alan.gauld at btinternet.com (Alan Gauld) Date: Sat, 7 Nov 2015 12:53:25 +0000 Subject: [Idle-dev] Running beginner Pythons In-Reply-To: References: Message-ID: On 10/10/15 20:18, Terry Reedy wrote: >> 1. Simple looping: >> 2. Simple function call: >> 3. Simple Native language keywords. While I don't think these things belong in Idle (if they even belong in Python) > 4. Visible leading spaces (or even all spaces). There is a unicode > small middle dot char that is suitable for this. This is a purely display item and definitely could be an IDLE (or any other IDE) feature. It would even be useful for posting code to mailing lists since HTML mail tools constantly lose spaces in posts. This could help ensure clear indentation in posts. I'd certainly vote for this as a switchable feature in Idle. PS. How would tab indents be handled? One mark or two? or expand tabs to 'spaces'? -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos From aivar.annamaa at ut.ee Thu Nov 12 06:05:51 2015 From: aivar.annamaa at ut.ee (Aivar Annamaa) Date: Thu, 12 Nov 2015 13:05:51 +0200 Subject: [Idle-dev] Running beginner Pythons Message-ID: <5644728F.3000400@ut.ee> Hi! Maybe we should add a different interface for constructing standard Python programs? Grace (http://gracelang.org/applications/) is a textual language meant for learning programs and they built a Scratch-like editor for constructing Grace programs (http://homepages.ecs.vuw.ac.nz/~mwh/minigrace/tiled , http://homepages.ecs.vuw.ac.nz/~mwh/vissoft2014.pdf) Similar thing could be done for Python. In fact, some of my students have already created a prototype: https://github.com/taivop/Monty I have plans to integrate this into Thonny, a Python IDE meant for beginners (http://thonny.cs.ut.ee/ , http://dl.acm.org/citation.cfm?id=2729094.2754849&coll=DL&dl=GUIDE&CFID=729521140&CFTOKEN=81247902). We recently used it successfully for teaching 1000 learners in a MOOC organized by University of Tartu. I agree with Serhiy that IDLE is not best place for such experiments. Thonny, on the other hand is built specifically for beginners and we welcome all kinds of new ideas. There is a plugin API available (not documented yet, but I'll get to it very soon). best regards, Aivar From andre.roberge at gmail.com Thu Nov 12 06:53:09 2015 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 12 Nov 2015 07:53:09 -0400 Subject: [Idle-dev] Running beginner Pythons Message-ID: On Thu, Nov 12, 2015 at 7:05 AM, Aivar Annamaa wrote: > Hi! > > Maybe we should add a different interface for constructing standard Python > programs? > > > Yes! > > I agree with Serhiy that IDLE is not best place for such experiments. I thought that Serhiy's comment was to limit IDLE to Python programming (and not other programming languages). > Thonny, on the other hand is built specifically for beginners and we > welcome all kinds of new ideas. There is a plugin API available (not > documented yet, but I'll get to it very soon). > > I think that having a plugin API for IDLE would be very useful, especially for enabling a different interface to construct Python program and send them to IDLE's editor window. I can imagine one such interface for using the Turtle module. Such interfaces could be especially useful for touch-enabled devices. For a concrete example of what I mean by this, go to http://reeborg.ca/world.html and click on "Reeborg's keyboard". Andr? > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Mon Nov 16 07:54:35 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 16 Nov 2015 07:54:35 -0500 Subject: [Idle-dev] breaking up is hard to do... In-Reply-To: <7B4C399C-089C-4283-B57E-529AD187EFBA@markroseman.com> References: <7B4C399C-089C-4283-B57E-529AD187EFBA@markroseman.com> Message-ID: On 9/4/2015 3:18 PM, Mark Roseman wrote: > Goals: > 1. split off tangential features from mega-modules (EditorWindow and PyShell) > 2. better encapsulation; reduce internal knowledge about other modules > 3. reduce assumptions affecting how UI assembled (e.g. toplevels) > 4. reduce redundancies > 5. make it easier for new IDLE contributors to navigate code base Agreed to all; started on #5 with new readme with index to files. > Non-goals (for now anyway): > 1. internal API stability > 2. supporting people using pieces of idlelib > 3. keeping third party IDLE extensions working These have to be kept for 2.7 & 3.5, but method will be to keep obsolete files around for now. 3.6 is a different question. > 4. keeping existing tests working Each test file must pass. If patch makes individual tests fail, we will have to either rewrite or remove. So agreed at individual assert level, which I presume is what you meant, not at file level. > Work Items: > > 1. Define a "IdleComponent" class (effectively a frame or toplevel). Examples would be editor windows, shell, prefs dialog, etc. Base class provides an API for various responsibilities, notifications etc. that can be handled in subclasses if needed. > 2. Replace WindowList, FileList, PyShellFileList with a smarter "hub" that ties all the pieces of the application together (see previous point). Also serves as a way to broadcast changes application wide, manage overall application state, etc. It is hard to evaluate things that do not exist ;-). > > 3. Create a "IdleMainWindow" which would bundle together a tabbed editor, status bar, debug panel, shell area via paned windows etc. Keep this as simple as possible (delegating to other components) so that experimenting with how pieces are put together is easier. Key think is making it easy to assemble pieces, so there can be multiple bundles. > 4. Improve module level documentation to help people navigating code base. Clarify role of module within application. Specifically highlight modules that are present for Tk 8.4 compatibility only, so they can be later removed. Module and functions docstrings are an ongoing project since a couple of years. > 5. EditorWindow - move all the help stuff into a separate module Partly done. > 6. EditorWindow - trim responsibilities so it handles "just" editor stuff. For example, things about launching dialogs, creating menu bars, etc. should get moved elsewhere. Should only respond to editor-related menu commands, while more 'application level' menu commands get done elsewhere. Agreed. > 7. Abstract/centralize all the menu management, key bindings etc. as required, delegating minimum amount needed to IdleComponent subclasses. Will likely center around the notion of commands (which may be equivalent to the virtual events used now), but components shouldn't have to mess with menus (would enable putting toolbars etc. in later if desired) > > 8. PyShell - split ModifiedInterpreter, Pseudo*File into other modules, strip PyShell class to core functionality like with EditorWindow (e.g. move debugger commands elsewhere). This module is a prime candidate to have everything moved elsewhere, leaving it basically as a main application startup script. > > 9. Make it so that we always have a Python shell/interpreter (like we do now) and a debugger object (or wrapper) available, even if they're not onscreen. Ideally separate debugger at least from a UI, so that UI can be created as needed and attach to underlying object. -- Terry Jan Reedy From tjreedy at udel.edu Mon Nov 16 08:19:37 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 16 Nov 2015 08:19:37 -0500 Subject: [Idle-dev] Running beginner Pythons In-Reply-To: References: Message-ID: On 11/7/2015 7:53 AM, Alan Gauld wrote: >> 4. Visible leading spaces (or even all spaces). There is a unicode >> small middle dot char that is suitable for this. > > This is a purely display item and definitely could be an IDLE > (or any other IDE) feature. It would even be useful for > posting code to mailing lists since HTML mail tools > constantly lose spaces in posts. This could help ensure > clear indentation in posts. > > I'd certainly vote for this as a switchable feature in Idle. > > PS. How would tab indents be handled? One mark or two? There was an issue requesting 'visible tabs' and I believe I closed it because it is too messy an issue. It cannot work consistently with proportional type because there may not be enough space for a character. > expand tabs to 'spaces'? That is what IDLE does now be default at beginning of lines. After chars, it TAB opens completions box. -- Terry Jan Reedy From tjreedy at udel.edu Mon Nov 16 08:54:26 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Mon, 16 Nov 2015 08:54:26 -0500 Subject: [Idle-dev] pending changes In-Reply-To: References: Message-ID: On 10/27/2015 5:27 AM, Terry Reedy wrote: > On 10/26/2015 1:15 AM, Terry Reedy wrote: >> On 10/22/2015 12:25 PM, Mark Roseman wrote: >>> A few incremental issues still to be reviewed/integrated: > > Since pushing 12+ patches for 10 issues in 2 weeks (September/October), > I have focused on Python/IDLE startup problems. The changes for Windows > in 3.5.0 introduced some new ones, some of which affect IDLE. For > instance, when IDLE starts from the icon, the usual case, it starts in > /Windows/system32 instead of the install directory. Two or three people > reported problems with this. These multiple unanticipated new problems > have made me a bit more cautious. Making IDLE pretty is not much good > if people cannot run it. > >>> 24455 (fix-mainloop2.patch) fix debugger crash caused by nested main >>> loops I am looking at this now. Review and questions: Issue 15347 has fix-nested-mainloop.patch, superceded by Issue 24455, fix-mainloop2.patch. This has 2 tk calls. self.root.tk.call('vwait', '::idledebugwait') self.root.tk.call('set', '::idledebugwait', '1') My naive guess is that the second is sets a variable to 1 and the first waits (how long, indefinitely?) until it is set to 1. Please verify/explain here or perhaps better on the issue. I dislike committing code I don't understand, and that future maintainers might also have a problem with. Say something on the issue and I will add a comment referring to it. #15347 also has remove-interacting-debugger.patch, to be applied on top of preceding. Do you consider this also ready to go? Issue15348 has two patches by Roger Serwy. What relation, if any, is there between your two and his? Supercede? Address different though seemingly related issues? >>> 25313 (missingtheme.patch) isolate code to default to ?idle classic? on >>> missing theme in one place > > I am nearly done with my alternative patch. That is about next on my > agenda. Done >>> 24750 (mainwin3.patch) correct visual inconsistencies in editor window >>> (most jarring and noticeable on mac Done -- Terry Jan Reedy From mark at markroseman.com Tue Nov 17 19:20:39 2015 From: mark at markroseman.com (Mark Roseman) Date: Tue, 17 Nov 2015 16:20:39 -0800 Subject: [Idle-dev] pending changes In-Reply-To: References: Message-ID: <8A9E1BA0-8404-4C55-8104-34C0C4B3D421@markroseman.com> > On Nov 16, 2015, at 5:54 AM, Terry Reedy wrote: > On 10/27/2015 5:27 AM, Terry Reedy wrote: >> On 10/26/2015 1:15 AM, Terry Reedy wrote: >>> On 10/22/2015 12:25 PM, Mark Roseman wrote: >>>> A few incremental issues still to be reviewed/integrated: >> >> Since pushing 12+ patches for 10 issues in 2 weeks (September/October), >> I have focused on Python/IDLE startup problems. The changes for Windows >> in 3.5.0 introduced some new ones, some of which affect IDLE. For >> instance, when IDLE starts from the icon, the usual case, it starts in >> /Windows/system32 instead of the install directory. Two or three people >> reported problems with this. These multiple unanticipated new problems >> have made me a bit more cautious. Making IDLE pretty is not much good >> if people cannot run it. Or if it?s that ugly and horrible, not having it start could save them the pain. ;-) >> >>>> 24455 (fix-mainloop2.patch) fix debugger crash caused by nested main >>>> loops > > I am looking at this now. Review and questions: > Issue 15347 has fix-nested-mainloop.patch, superceded by > Issue 24455, fix-mainloop2.patch. This has 2 tk calls. > self.root.tk.call('vwait', '::idledebugwait') > self.root.tk.call('set', '::idledebugwait', '1') > > My naive guess is that the second is sets a variable to 1 and the first waits (how long, indefinitely?) until it is set to 1. Please verify/explain here or perhaps better on the issue. I dislike committing code I don't understand, and that future maintainers might also have a problem with. Say something on the issue and I will add a comment referring to it. The code in the patch for 24455 has this comment on it: + # Nested main loop: Tkinter's main loop is not reentrant, so use + # Tcl's vwait facility, which reenters the event loop until an + # event handler sets the variable we're waiting on This creates a new (in this case, nested) event loop. That event loop will only be terminated when that variable is written to. Or in other words: loop forever pull next event from the event queue process that event if processing that event caused the variable we?re watching to be set (to anything) break out of the loop So in this context, we?re essentially sitting in that code at the vwait until we press a button on the UI to continue, etc. This is because what?s actually happening is our other interpreter is busy running our program, which calls back into us on every statement, i.e.: about to run first statement ?> callback to program run first statement about to run second statement ?> callback to program If we didn?t do the nested loop (i.e. not return from the callback) we?d run through our program start to finish. The vwait replaces self.root.mainloop which it turns out cannot be called in a reentrant fashion (it modifies various global state variables). FYI: documentation on vwait: https://www.tcl.tk/man/tcl/TclCmd/vwait.htm > #15347 also has remove-interacting-debugger.patch, to be applied on top of preceding. Do you consider this also ready to go? Yes > Issue15348 has two patches by Roger Serwy. What relation, if any, is there between your two and his? Supercede? Address different though seemingly related issues? Roger?s patches try to work around the bad behaviour caused by the (broken) nested mainloop. Mine actually fix the underlying root cause so Roger?s patches are then no longer needed. The horrific comment in run() in fix-mainloop2.patch describes things in a bit more detail in terms of what was happening before and what?s changed. > >>>> 25313 (missingtheme.patch) isolate code to default to ?idle classic? on >>>> missing theme in one place >> >> I am nearly done with my alternative patch. That is about next on my >> agenda. > > Done > >>>> 24750 (mainwin3.patch) correct visual inconsistencies in editor window >>>> (most jarring and noticeable on mac > > Done Thank you kindly on the latter (as you know, was my pet annoyance) :-) Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Sat Nov 21 13:50:55 2015 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 21 Nov 2015 13:50:55 -0500 Subject: [Idle-dev] pending changes In-Reply-To: <8A9E1BA0-8404-4C55-8104-34C0C4B3D421@markroseman.com> References: <8A9E1BA0-8404-4C55-8104-34C0C4B3D421@markroseman.com> Message-ID: On 11/17/2015 7:20 PM, Mark Roseman wrote: >> On Nov 16, 2015, at 5:54 AM, Terry Reedy >>>> 24455 (fix-mainloop2.patch) fix debugger crash caused by nested main >>>>> loops >> >> I am looking at this now. Committed, along with additional patch for #15347. [Mark's explanation] > FYI: documentation on vwait: https://www.tcl.tk/man/tcl/TclCmd/vwait.htm Thanks. I think I got the somewhat baroque ping-ponging of execution control somewhat clear. >> #15347 also has remove-interacting-debugger.patch, to be applied on >> top of preceding. Do you consider this also ready to go? > > Yes Not done yet. I want to do more testing, including with -n, after my additional patch. I want to understand why 'interacting' seems to have no effect before removing it. >> Issue15348 has two patches by Roger Serwy. What relation, if any, is >> there between your two and his? Supercede? Address different though >> seemingly related issues? > > Roger?s patches try to work around the bad behaviour caused by the > (broken) nested mainloop. Mine actually fix the underlying root cause > so Roger?s patches are then no longer needed. I identified one shutdown situation which is not handled properly yet, and may not have been Roger's patch either. Gracefully shutting down the debugger without bad side-effects is not trivial. But we have improved several cases. -- Terry Jan Reedy From beni.cherniavsky at gmail.com Thu Nov 12 06:55:52 2015 From: beni.cherniavsky at gmail.com (Beni Cherniavsky-Paskin) Date: Thu, 12 Nov 2015 11:55:52 -0000 Subject: [Idle-dev] Running beginner Pythons In-Reply-To: <5644728F.3000400@ut.ee> References: <5644728F.3000400@ut.ee> Message-ID: If IDLE is special for education simply because it comes installed out of the box[1], perhaps what educators would really want is that IDLE included an easy way to fetch any package from PyPI? (Ideally, installing into a virtualenv that doesn't affect the machine, to keep admins less anxious, and to allow easy resetting to clean slate.) [1] There is also the fact that IDLE is simple, but here we're talking about radical departures that could be easier outside, if the root issue of installing stuff was solved... 2015-11-12 13:05 GMT+02:00 Aivar Annamaa : > Hi! > > Maybe we should add a different interface for constructing standard Python > programs? > > Grace (http://gracelang.org/applications/) is a textual language meant > for learning programs and they built a Scratch-like editor for constructing > Grace programs (http://homepages.ecs.vuw.ac.nz/~mwh/minigrace/tiled , > http://homepages.ecs.vuw.ac.nz/~mwh/vissoft2014.pdf) > > Similar thing could be done for Python. In fact, some of my students have > already created a prototype: https://github.com/taivop/Monty > > I have plans to integrate this into Thonny, a Python IDE meant for > beginners (http://thonny.cs.ut.ee/ , > http://dl.acm.org/citation.cfm?id=2729094.2754849&coll=DL&dl=GUIDE&CFID=729521140&CFTOKEN=81247902). > We recently used it successfully for teaching 1000 learners in a MOOC > organized by University of Tartu. > > I agree with Serhiy that IDLE is not best place for such experiments. > Thonny, on the other hand is built specifically for beginners and we > welcome all kinds of new ideas. There is a plugin API available (not > documented yet, but I'll get to it very soon). > > best regards, > Aivar > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k0m0d0dr490n at gmail.com Sat Nov 14 21:25:07 2015 From: k0m0d0dr490n at gmail.com (komodo dragon) Date: Sun, 15 Nov 2015 02:25:07 -0000 Subject: [Idle-dev] Backslash on IDLE results to Yen symbol Message-ID: Hi, How can I get IDLE to show a backslash instead of a yen symbol? I have no problems with this when I'm using notepad++ and python shell (please see attached file). I have tried different key combinations such as alt, ctrl and fn with backslash key but none of them works. I am running IDLE version 3.5.0. Thanks, K0m0d0[image: Capture1111.JPG] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture1111.JPG Type: image/jpeg Size: 59457 bytes Desc: not available URL: From k0m0d0dr490n at gmail.com Fri Nov 20 22:12:18 2015 From: k0m0d0dr490n at gmail.com (komodo dragon) Date: Sat, 21 Nov 2015 03:12:18 -0000 Subject: [Idle-dev] Backslash on IDLE results to Yen symbol In-Reply-To: References: Message-ID: Hi again, I was wondering if you were able to look into this? I tried the backslash again and now this is what happens (please see attached file). The first one is with IDLE, the second is the terminal and the third is notepad++. I'm using a custom theme on this but I tried using the default themes (classic and new) but the same thing happens. I'm on the following: OS - Win 10 Unit - Compaq Presario CQ56[image: Capture1112.JPG] Thank you, k0m0d0 On Sun, Nov 15, 2015 at 10:24 AM komodo dragon wrote: > Hi, > > How can I get IDLE to show a backslash instead of a yen symbol? I have no > problems with this when I'm using notepad++ and python shell (please see > attached file). I have tried different key combinations such as alt, ctrl > and fn with backslash key but none of them works. > > I am running IDLE version 3.5.0. > > Thanks, > > K0m0d0[image: Capture1111.JPG] > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture1111.JPG Type: image/jpeg Size: 59457 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture1112.JPG Type: image/jpeg Size: 66031 bytes Desc: not available URL: