From roger.serwy at gmail.com Thu Jul 12 06:24:07 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Wed, 11 Jul 2012 23:24:07 -0500 Subject: [Idle-dev] Deprecate running IDLE without a subprocess In-Reply-To: References: <4FD68525.3040706@illinois.edu> Message-ID: <4FFE5167.1040206@gmail.com> From what I've read in this thread, Linux, Mac, and Windows all seem to fully support the subprocess without issue. Should I open an issue on the bug tracker for deprecating "-n" ? On 06/24/2012 05:32 AM, Tal Einat wrote: > On Tue, Jun 12, 2012 at 2:54 AM, serwy > wrote: > > IDLE developers, > > In the interest of simplifying IDLE's code, I suggest that running > IDLE *without* a subprocess be deprecated. Since 2009, IDLE could > have multiple instances running while using a subprocess. See > http://bugs.python.org/ issue1529142 > > > Running without a subprocess has a flaw in that Ctrl+C from the > IDLE GUI can not be used to stop a program. This can be irritating > to Python beginners if an accidental infinite loop arises and the > user's only recourse is to restart IDLE, losing any unsaved work > in the editor windows. > > What are your thoughts? > > > IIRC, the major reason for keeping around no-subprocess mode was > because IDLE always used the same port for communicating with its > subprocess. Therefore, running more than one instance of IDLE at the > same time would never work, and even closing IDLE and running it again > quickly would sometimes fail. This is no longer an issue since IDLE > now uses a random port given by the OS (by opening the socket on TCP > port zero - it took me years to discover that trick!). > > Other reasons for keeping no-subprocess mode around: > * debugging IDLE is significantly easier when everything is in a > single process > * some firewall software would occasionally block the connection to > the subprocess, or perhaps just raise a warning (but I guess this is > no longer a real issue; the old firewall warning message has been removed) > > In my opinion, if the IDLE developers are confident in their ability > to debug IDLE running with a sub-process, then there is no significant > reason not to remove the no-subprocess mode. From what I remember > about the code, this would allow simplifying things significantly in > many places. > > - Tal Einat -------------- next part -------------- An HTML attachment was scrubbed... URL: From memilanuk at gmail.com Tue Jul 17 17:18:46 2012 From: memilanuk at gmail.com (Monte Milanuk) Date: Tue, 17 Jul 2012 15:18:46 +0000 (UTC) Subject: [Idle-dev] Integrate pep8 into IDLE? Message-ID: Just a thought... since pep8 is supposed to be *the* standard for python coding, and IDLE is the default 'IDE' included for beginning use... would it not make a certain amount of sense to integrate pep8 into IDLE so as to encourage new users to code to the standard... From tjreedy at udel.edu Tue Jul 17 20:58:23 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 17 Jul 2012 14:58:23 -0400 Subject: [Idle-dev] Integrate pep8 into IDLE? In-Reply-To: References: Message-ID: On 7/17/2012 11:18 AM, Monte Milanuk wrote: > Just a thought... since pep8 is supposed to be *the* standard for python coding, > and IDLE is the default 'IDE' included for beginning use... would it not make a > certain amount of sense to integrate pep8 into IDLE so as to encourage new users > to code to the standard... If you mean 'enforce' pep8, that is out of the question. If you mean 'run a style checker' (as a new option of the run submene*) , I suspect there may already be an idle extension for that. If and when we get idle somewhat properly documented, that would include doc of the extension mechanism and perhaps suggestions of some good ones. Or we might include more that we do now. * I had to look on the help page to fine that 'check module' means 'check syntax'. Anyone disagree that the latter is clearer? -- Terry Jan Reedy From memilanuk at gmail.com Tue Jul 17 21:49:22 2012 From: memilanuk at gmail.com (Monte Milanuk) Date: Tue, 17 Jul 2012 19:49:22 +0000 (UTC) Subject: [Idle-dev] Integrate pep8 into IDLE? References: Message-ID: Terry Reedy udel.edu> writes: > If you mean 'enforce' pep8, that is out of the question. No, of course not. I realize that pep8 is meant as a style 'guide', not a hard-n-fast rule... and that some other packages/frameworks (such as PyQt, for example) do use various forms of camelCase. > If you mean > 'run a style checker' (as a new option of the run submene*) , I suspect > there may already be an idle extension for that. If and when we get idle > somewhat properly documented, that would include doc of the extension > mechanism and perhaps suggestions of some good ones. Or we might include > more that we do now. > That would be great. Seems like there has been more interest/activity in improving IDLE over the past year or two... hopefully some of the more visible improvements/extensions will begin making it to the mainstream 'official' version of IDLE at some point? From tjreedy at udel.edu Tue Jul 17 22:06:09 2012 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 17 Jul 2012 16:06:09 -0400 Subject: [Idle-dev] Integrate pep8 into IDLE? In-Reply-To: References: Message-ID: On 7/17/2012 3:49 PM, Monte Milanuk wrote: > That would be great. Seems like there has been more interest/activity in > improving IDLE over the past year or two... hopefully some of the more visible > improvements/extensions will begin making it to the mainstream 'official' > version of IDLE at some point? I really got going on Idle only last January, mostly modifying and applying Roger Serwy's patches. We (at least me) are first concentrating on fixing the bugs that crash or close Idle, and a few major irritants. I really do hope to move on to improvements at some point. -- Terry Jan Reedy From roger.serwy at gmail.com Tue Jul 17 22:56:08 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Tue, 17 Jul 2012 15:56:08 -0500 Subject: [Idle-dev] Integrate pep8 into IDLE? In-Reply-To: References: Message-ID: <5005D168.4080304@gmail.com> On 07/17/2012 01:58 PM, Terry Reedy wrote: > On 7/17/2012 11:18 AM, Monte Milanuk wrote: >> Just a thought... since pep8 is supposed to be *the* standard for >> python coding, >> and IDLE is the default 'IDE' included for beginning use... would it >> not make a >> certain amount of sense to integrate pep8 into IDLE so as to >> encourage new users >> to code to the standard... > > If you mean 'enforce' pep8, that is out of the question. If you mean > 'run a style checker' (as a new option of the run submene*) , I > suspect there may already be an idle extension for that. If and when > we get idle somewhat properly documented, that would include doc of > the extension mechanism and perhaps suggestions of some good ones. Or > we might include more that we do now. I'm unaware of a publicly available PEP-8 style check extension for IDLE. There is a checker available on pypi:(http://pypi.python.org/pypi/pep8). All IDLE extension in the standard distribution only call into the standard library. An extension which relies on pep8.py would likely need to be distributed separately. If you are looking to write an extension, check out the IdleX project. The Horizontal.py extension is designed as an example for writing IDLE extensions. > * I had to look on the help page to fine that 'check module' means > 'check syntax'. Anyone disagree that the latter is clearer? The menu has several slightly unclear items. I agree that "check syntax" is clearer than "check module". - Roger From ether.joe at gmail.com Wed Jul 18 01:57:13 2012 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Tue, 17 Jul 2012 16:57:13 -0700 Subject: [Idle-dev] December bugfix email + IDLE dev status Message-ID: Hello all, I remember in December there was a call for bugfixes on the IDLE codebase. I'm poking around IDLE again and also getting up to speed on GTK for another project, which should help provide some food for thought. I'm wondering if that call from December for help is still a going concern? I'm not super experienced yet on the technologies involved but I'm learning quickly and I'd love to help out. Thanks! -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow From roger.serwy at gmail.com Wed Jul 18 22:49:46 2012 From: roger.serwy at gmail.com (Roger Serwy) Date: Wed, 18 Jul 2012 15:49:46 -0500 Subject: [Idle-dev] December bugfix email + IDLE dev status In-Reply-To: References: Message-ID: <5007216A.8070706@gmail.com> Hi Sean, Fixing IDLE is still a priority. Feel free to check out the issues on the bug tracker. IDLE uses Tk, not GTK, for its widgets. The general concepts are the same but the specifics are different. Cheers, Roger On 07/17/2012 06:57 PM, Sean Felipe Wolfe wrote: > Hello all, I remember in December there was a call for bugfixes on the > IDLE codebase. I'm poking around IDLE again and also getting up to > speed on GTK for another project, which should help provide some food > for thought. I'm wondering if that call from December for help is > still a going concern? > > I'm not super experienced yet on the technologies involved but I'm > learning quickly and I'd love to help out. > > Thanks! > From ether.joe at gmail.com Thu Jul 26 03:03:21 2012 From: ether.joe at gmail.com (Sean Felipe Wolfe) Date: Wed, 25 Jul 2012 18:03:21 -0700 Subject: [Idle-dev] December bugfix email + IDLE dev status In-Reply-To: <5007216A.8070706@gmail.com> References: <5007216A.8070706@gmail.com> Message-ID: On Wed, Jul 18, 2012 at 1:49 PM, Roger Serwy wrote: > Hi Sean, > > Fixing IDLE is still a priority. Feel free to check out the issues on the > bug tracker. > > IDLE uses Tk, not GTK, for its widgets. The general concepts are the same > but the specifics are different. > > Cheers, > Roger I'm on the tracker now takin a look. Regarding http://bugs.python.org/issue15392, create a unittest framework for IDLE... this is actually something I do in my day job... sorta. I write UI tests for Android apps and I've also used unittest a fair amount in the past. So maybe I can help out here. Bugs with patches, should be reproducible until I manually install the patch, correct? Thanks!