From kbk at shore.net  Wed Sep  2 06:11:55 2015
From: kbk at shore.net (kbk at shore.net)
Date: Wed, 2 Sep 2015 08:11:55 +0400
Subject: [Idle-dev] [Spam][Cured]Returned mail: Data format error
Message-ID: <201509020510.t825APx7039244@gw.ufps.lipetsk.ru>

The original message was received at Wed, 2 Sep 2015 08:11:55 +0400
from shore.net [60.83.147.237]

----- The following addresses had permanent fatal errors -----
<idle-dev at python.org>

----- Transcript of session follows -----
  while talking to python.org.:
>>> MAIL From:kbk at shore.net
<<< 501 kbk at shore.net... Refused



-------------- next part --------------
A non-text attachment was scrubbed...
Name: file.zip
Type: application/octet-stream
Size: 22 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150902/a621ab2d/attachment.obj>

From chris at codingclub.co.uk  Wed Sep  2 13:42:50 2015
From: chris at codingclub.co.uk (Chris Roffey)
Date: Wed, 2 Sep 2015 12:42:50 +0100
Subject: [Idle-dev] walkthrough/snapshot of IDLE user interface
	improvements to date
In-Reply-To: <4508C042-0ECC-4E69-BD54-F68299B2269C@markroseman.com>
References: <4508C042-0ECC-4E69-BD54-F68299B2269C@markroseman.com>
Message-ID: <1D0133C8-37B9-4043-910C-E66F1C2DCFA9@codingclub.co.uk>

Dear Mark

This is excellent! It is humbling to see how much work is done by a dedicated few on IDLE development.
I have read  through the document you linked to and found it very interesting. Ensuring IDLE looks professional and natural on all platforms is very important for students (the biggest cohort of beginners) as they make first impressions very quickly. Getting rid of annoying bugs is also very important as it gives one less thing for students to moan about - remember, learning to program, requires a great deal of persistence and resilience - every unnecessary obstacle is a potential turn-off for possibly able students. So all the IDLE-dev team?s hard work on this is invaluable.

Keeping things simple appears to be a mantra of this group - and it is a good one. I am no longer convinced that having a complete panelled IDLE interface like I suggested before is necessary or even the best option. I now think that keeping any windowed apps (using tkinter or turtle modules) out of the interface simplifies and makes it more flexible as long as they appear on top when run. There was a time when turtle windows appeared behind the shell window and the script window meaning a lot of the turtle?s activity was missed while the window was found. This appears to be fixed and it appears front central now (on my Mac at least) ? perfect!

I have been developing my thoughts further trying to produce my ideal IDE/text editor for teaching with. I have called it CREATE rather than IDLE so that it is easier to refer to (rather than Chris Roffey?s possible version of IDLE.) 

http://codingclub.co.uk/images/CREATE-overview.png

Feature wise, I am not sure that it is very challenging in terms of programming as I am not suggesting many feature requests (except major things like ?Deploy' - that could be developed outside of this team and then linked to.) A lot of work would need to be done on documentation and aliases for error messages but this IS something I could help with. However, is tkinter up to the sort of sliding panels I am suggesting? Mark, please sit down for this next question - I am loath to make it as I know how much work people have already done and I am well aware I am new to the group but - would it be better to use a more sophisticated system for the graphical side of IDLE that implements platform native windowing facilities and allows for style sheets? This might take away some of the complexities of implementing tkinter features for the users whilst running tkinter in the IDE - I don?t know?

The reason I make such bold statements is I am aware of the trend in education recently is to produce fantastic drag and drop environments for students coding prior to learning a text based language like Python e.g. Scratch (fantastic), Kodu (not so sure). So to make a good impression, any IDE needs to compete at least in terms of looks and ease of use with these. Although I agree with others on this group that IDLE should not be trying to compete with professional IDEs currently available - I do think that students deserve something as sophisticated and professional as the developers, but written with them in mind.

The question is, should and could IDLE do this?

Best wishes
Chris

> On 31 Aug 2015, at 20:44, Mark Roseman <mark at markroseman.com> wrote:
> 
> As I?ve been making changes to various pieces of IDLE?s user interface, I?ve been documenting the updates in the form of a case study. I hope that will be useful to others modernizing a Tk-based application. I?ve put a draft of that, as well as a snapshot of the current code, here:
> 
> 	http://www.tkdocs.com/tutorial/idle.html
> 
> I?m looking forward to helping do whatever I can to migrate some of these changes into IDLE?s official codebase. But in the meantime if anyone can take a read or try the code, that would be great!
> 
> Some of the deeper changes to allow (cleanly) for more of a single window model will probably have to wait until a few more of these preliminaries find their way in.
> 
> Mark
> 
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> https://mail.python.org/mailman/listinfo/idle-dev


From al at inventwithpython.com  Thu Sep  3 01:04:53 2015
From: al at inventwithpython.com (Al Sweigart)
Date: Wed, 2 Sep 2015 16:04:53 -0700
Subject: [Idle-dev] walkthrough/snapshot of IDLE user interface
 improvements to date
In-Reply-To: <1D0133C8-37B9-4043-910C-E66F1C2DCFA9@codingclub.co.uk>
References: <4508C042-0ECC-4E69-BD54-F68299B2269C@markroseman.com>
 <1D0133C8-37B9-4043-910C-E66F1C2DCFA9@codingclub.co.uk>
Message-ID: <CAM=hmRP56Ty1WcREu-jCDP5x4k1ApFdrM4U72k6VSn3Q7H8-nw@mail.gmail.com>

Hi Chris. I believe Mark is working on getting IDLE to be able to use more
native-looking widgets with his tkinter work. As for "style sheets", IDLE
already has something similar to this with the customizable syntax
highlighting. I have some loose ideas for how this could be improved, and I
was thinking that once the unified interactive shell/file editor window was
done, updating the colors would be a good idea to give the "new IDLE" a
more distinctive look (maybe something along the lines of Sublime Text's
color scheme).

These are just idle thoughts, so to speak, and far from an actual proposal
on my part.

-Al

On Wed, Sep 2, 2015 at 4:42 AM, Chris Roffey <chris at codingclub.co.uk> wrote:

> Dear Mark
>
> This is excellent! It is humbling to see how much work is done by a
> dedicated few on IDLE development.
> I have read  through the document you linked to and found it very
> interesting. Ensuring IDLE looks professional and natural on all platforms
> is very important for students (the biggest cohort of beginners) as they
> make first impressions very quickly. Getting rid of annoying bugs is also
> very important as it gives one less thing for students to moan about -
> remember, learning to program, requires a great deal of persistence and
> resilience - every unnecessary obstacle is a potential turn-off for
> possibly able students. So all the IDLE-dev team?s hard work on this is
> invaluable.
>
> Keeping things simple appears to be a mantra of this group - and it is a
> good one. I am no longer convinced that having a complete panelled IDLE
> interface like I suggested before is necessary or even the best option. I
> now think that keeping any windowed apps (using tkinter or turtle modules)
> out of the interface simplifies and makes it more flexible as long as they
> appear on top when run. There was a time when turtle windows appeared
> behind the shell window and the script window meaning a lot of the turtle?s
> activity was missed while the window was found. This appears to be fixed
> and it appears front central now (on my Mac at least) ? perfect!
>
> I have been developing my thoughts further trying to produce my ideal
> IDE/text editor for teaching with. I have called it CREATE rather than IDLE
> so that it is easier to refer to (rather than Chris Roffey?s possible
> version of IDLE.)
>
> http://codingclub.co.uk/images/CREATE-overview.png
>
> Feature wise, I am not sure that it is very challenging in terms of
> programming as I am not suggesting many feature requests (except major
> things like ?Deploy' - that could be developed outside of this team and
> then linked to.) A lot of work would need to be done on documentation and
> aliases for error messages but this IS something I could help with.
> However, is tkinter up to the sort of sliding panels I am suggesting? Mark,
> please sit down for this next question - I am loath to make it as I know
> how much work people have already done and I am well aware I am new to the
> group but - would it be better to use a more sophisticated system for the
> graphical side of IDLE that implements platform native windowing facilities
> and allows for style sheets? This might take away some of the complexities
> of implementing tkinter features for the users whilst running tkinter in
> the IDE - I don?t know?
>
> The reason I make such bold statements is I am aware of the trend in
> education recently is to produce fantastic drag and drop environments for
> students coding prior to learning a text based language like Python e.g.
> Scratch (fantastic), Kodu (not so sure). So to make a good impression, any
> IDE needs to compete at least in terms of looks and ease of use with these.
> Although I agree with others on this group that IDLE should not be trying
> to compete with professional IDEs currently available - I do think that
> students deserve something as sophisticated and professional as the
> developers, but written with them in mind.
>
> The question is, should and could IDLE do this?
>
> Best wishes
> Chris
>
> > On 31 Aug 2015, at 20:44, Mark Roseman <mark at markroseman.com> wrote:
> >
> > As I?ve been making changes to various pieces of IDLE?s user interface,
> I?ve been documenting the updates in the form of a case study. I hope that
> will be useful to others modernizing a Tk-based application. I?ve put a
> draft of that, as well as a snapshot of the current code, here:
> >
> >       http://www.tkdocs.com/tutorial/idle.html
> >
> > I?m looking forward to helping do whatever I can to migrate some of
> these changes into IDLE?s official codebase. But in the meantime if anyone
> can take a read or try the code, that would be great!
> >
> > Some of the deeper changes to allow (cleanly) for more of a single
> window model will probably have to wait until a few more of these
> preliminaries find their way in.
> >
> > Mark
> >
> > _______________________________________________
> > IDLE-dev mailing list
> > IDLE-dev at python.org
> > https://mail.python.org/mailman/listinfo/idle-dev
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150902/297c8969/attachment.html>

From mark at markroseman.com  Thu Sep  3 02:28:28 2015
From: mark at markroseman.com (Mark Roseman)
Date: Wed, 2 Sep 2015 17:28:28 -0700
Subject: [Idle-dev] walkthrough/snapshot of IDLE user interface
	improvements to date
In-Reply-To: <1D0133C8-37B9-4043-910C-E66F1C2DCFA9@codingclub.co.uk>
References: <4508C042-0ECC-4E69-BD54-F68299B2269C@markroseman.com>
 <1D0133C8-37B9-4043-910C-E66F1C2DCFA9@codingclub.co.uk>
Message-ID: <4FDECA50-F797-44A6-80D1-404D31ED9B15@markroseman.com>

Hi Chris, and thanks very much for the time and effort you put into sharing your thoughts and ideas.

The kind of ?sliding panels? you describe can be accomplished easily enough with Tkinter (even the older versions, without too much hassle). The bigger issue  is teasing apart some of the monolithic pieces in IDLE now that assume each component has its own window, and how certain components have overly intimate knowledge of each other. Doing that would make it easier to experiment with putting things together in new and interesting ways. 

(I?ve spent a couple of days going through it and know how I?d like to see things broken up and reorganized, but it?s one of those things that is liable to break a lot of things before it eventually stabilizes, so I?m a bit stumped how best to proceed next.)

As for your drag and drop GUI builder addition - yes, that might well be a nice thing to have, but I think at this point you may be stepping beyond the realistic limitations of what might find its way into IDLE short-medium term. :-)  FWIW, there have been numerous GUI builder tools done for Tk (and hence Tkinter) in the past, so I?m not saying it?s not doable, and in fact it could be done as an add-on of some kind to start. So my hesitancy is not about the value and feasibility but that it is a substantial new direction of its own.

Thanks again
Mark



> On Sep 2, 2015, at 4:42 AM, Chris Roffey <chris at codingclub.co.uk> wrote:
> 
> Dear Mark
> 
> This is excellent! It is humbling to see how much work is done by a dedicated few on IDLE development.
> I have read  through the document you linked to and found it very interesting. Ensuring IDLE looks professional and natural on all platforms is very important for students (the biggest cohort of beginners) as they make first impressions very quickly. Getting rid of annoying bugs is also very important as it gives one less thing for students to moan about - remember, learning to program, requires a great deal of persistence and resilience - every unnecessary obstacle is a potential turn-off for possibly able students. So all the IDLE-dev team?s hard work on this is invaluable.
> 
> Keeping things simple appears to be a mantra of this group - and it is a good one. I am no longer convinced that having a complete panelled IDLE interface like I suggested before is necessary or even the best option. I now think that keeping any windowed apps (using tkinter or turtle modules) out of the interface simplifies and makes it more flexible as long as they appear on top when run. There was a time when turtle windows appeared behind the shell window and the script window meaning a lot of the turtle?s activity was missed while the window was found. This appears to be fixed and it appears front central now (on my Mac at least) ? perfect!
> 
> I have been developing my thoughts further trying to produce my ideal IDE/text editor for teaching with. I have called it CREATE rather than IDLE so that it is easier to refer to (rather than Chris Roffey?s possible version of IDLE.) 
> 
> http://codingclub.co.uk/images/CREATE-overview.png
> 
> Feature wise, I am not sure that it is very challenging in terms of programming as I am not suggesting many feature requests (except major things like ?Deploy' - that could be developed outside of this team and then linked to.) A lot of work would need to be done on documentation and aliases for error messages but this IS something I could help with. However, is tkinter up to the sort of sliding panels I am suggesting? Mark, please sit down for this next question - I am loath to make it as I know how much work people have already done and I am well aware I am new to the group but - would it be better to use a more sophisticated system for the graphical side of IDLE that implements platform native windowing facilities and allows for style sheets? This might take away some of the complexities of implementing tkinter features for the users whilst running tkinter in the IDE - I don?t know?
> 
> The reason I make such bold statements is I am aware of the trend in education recently is to produce fantastic drag and drop environments for students coding prior to learning a text based language like Python e.g. Scratch (fantastic), Kodu (not so sure). So to make a good impression, any IDE needs to compete at least in terms of looks and ease of use with these. Although I agree with others on this group that IDLE should not be trying to compete with professional IDEs currently available - I do think that students deserve something as sophisticated and professional as the developers, but written with them in mind.
> 
> The question is, should and could IDLE do this?
> 
> Best wishes
> Chris
> 
>> On 31 Aug 2015, at 20:44, Mark Roseman <mark at markroseman.com> wrote:
>> 
>> As I?ve been making changes to various pieces of IDLE?s user interface, I?ve been documenting the updates in the form of a case study. I hope that will be useful to others modernizing a Tk-based application. I?ve put a draft of that, as well as a snapshot of the current code, here:
>> 
>> 	http://www.tkdocs.com/tutorial/idle.html
>> 
>> I?m looking forward to helping do whatever I can to migrate some of these changes into IDLE?s official codebase. But in the meantime if anyone can take a read or try the code, that would be great!
>> 
>> Some of the deeper changes to allow (cleanly) for more of a single window model will probably have to wait until a few more of these preliminaries find their way in.
>> 
>> Mark
>> 
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
> 
> 


From mark at markroseman.com  Fri Sep  4 21:18:18 2015
From: mark at markroseman.com (Mark Roseman)
Date: Fri, 4 Sep 2015 12:18:18 -0700
Subject: [Idle-dev] breaking up is hard to do...
Message-ID: <7B4C399C-089C-4283-B57E-529AD187EFBA@markroseman.com>

Having fiddled around the edges long enough, I'd like to start tackling some of the main pieces of IDLE, which will require a substantial restructuring. Luckily, it's only about 4000-5000 lines of code that should be affected.

Outline of my tentative plans below. If anyone sees any red flags, speak up!


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

Non-goals (for now anyway):
1. internal API stability
2. supporting people using pieces of idlelib
3. keeping third party IDLE extensions working
4. keeping existing tests working

A special note on the last point. Adapting (relevant) existing tests, and filling in holes in testing needs to happen sooner than later. But because of how things will be broken up (hence destroying API stability) likely most of the tests will be broken to start with.

The other question of course is how this monstrosity of changes can be realistically condensed into a "patch", but I'll leave thinking about that for now.


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.

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.

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.

5. EditorWindow - move all the help stuff into a separate module

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.

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. 


From ether.joe at gmail.com  Sat Sep  5 00:28:28 2015
From: ether.joe at gmail.com (Sean Felipe Wolfe)
Date: Fri, 4 Sep 2015 15:28:28 -0700
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: <CAOFf2a29qG=iSg=bnD2X+cOU+XQBvzrLhYtOU6p_3qFnCWFJTg@mail.gmail.com>

Sounds awesome :)
On Sep 4, 2015 12:18 PM, "Mark Roseman" <mark at markroseman.com> wrote:

> Having fiddled around the edges long enough, I'd like to start tackling
> some of the main pieces of IDLE, which will require a substantial
> restructuring. Luckily, it's only about 4000-5000 lines of code that should
> be affected.
>
> Outline of my tentative plans below. If anyone sees any red flags, speak
> up!
>
>
> 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
>
> Non-goals (for now anyway):
> 1. internal API stability
> 2. supporting people using pieces of idlelib
> 3. keeping third party IDLE extensions working
> 4. keeping existing tests working
>
> A special note on the last point. Adapting (relevant) existing tests, and
> filling in holes in testing needs to happen sooner than later. But because
> of how things will be broken up (hence destroying API stability) likely
> most of the tests will be broken to start with.
>
> The other question of course is how this monstrosity of changes can be
> realistically condensed into a "patch", but I'll leave thinking about that
> for now.
>
>
> 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.
>
> 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.
>
> 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.
>
> 5. EditorWindow - move all the help stuff into a separate module
>
> 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.
>
> 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.
>
> _______________________________________________
> 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: <http://mail.python.org/pipermail/idle-dev/attachments/20150904/28902b5e/attachment.html>

From mark at markroseman.com  Sat Sep 19 22:58:39 2015
From: mark at markroseman.com (Mark Roseman)
Date: Sat, 19 Sep 2015 13:58:39 -0700
Subject: [Idle-dev] updated snapshot
Message-ID: <39CC1003-0BCA-435E-9D3C-A3049EB39524@markroseman.com>

As I?ve been working on IDLE improvements, I?ve been keeping a running snapshot of my current version here:
	https://github.com/roseman/idle <https://github.com/roseman/idle>

As of now, this includes:
- tabbed shell/editor windows
- incorporate ttk into various places when available
- new redesigned ttk-based, modeless preferences/options window
- new redesigned, modeless about window
- new modeless rich-text 'idle help' window
- redesigned 'ask' modal dialogs (e.g. go to line, open module, etc.)
- cosmetic tweaks to editor window, status bar, etc.
- fix positioning of several yes/no/cancel etc. type of dialogs
- fix windows not showing text found via dialogs until dialogs closed 
- fix calltips not working on mac
- fix debugger and editor context menus not working on mac

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150919/0d356232/attachment.html>

From rohan0495 at gmail.com  Tue Sep 22 19:52:17 2015
From: rohan0495 at gmail.com (Rohan Ds)
Date: Tue, 22 Sep 2015 23:22:17 +0530
Subject: [Idle-dev] Contributing to IDLE
Message-ID: <CAJdaWS4XvtgAWEDBg5P-JZQmkwme_q+HErv=UJEWB6X_nrvbRg@mail.gmail.com>

Hello everyone,

I am Rohan from India. Currently pursuing Bachelors in Engineering
(Computer Science). On interaction with a few people on the core mentorship
mailing list, I have been led to believe that there is some code
restructuring happening here.
I request one of you to assign some tasks to me as I'd love to contribute.

Thanking you,
Rohan Ds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150922/d0b82f47/attachment.html>

From tjreedy at udel.edu  Tue Sep 22 23:27:14 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 22 Sep 2015 17:27:14 -0400
Subject: [Idle-dev] Contributing to IDLE
In-Reply-To: <CAJdaWS4XvtgAWEDBg5P-JZQmkwme_q+HErv=UJEWB6X_nrvbRg@mail.gmail.com>
References: <CAJdaWS4XvtgAWEDBg5P-JZQmkwme_q+HErv=UJEWB6X_nrvbRg@mail.gmail.com>
Message-ID: <mtsh3o$upn$1@ger.gmane.org>

On 9/22/2015 1:52 PM, Rohan Ds wrote:
> I am Rohan from India. Currently pursuing Bachelors in Engineering
> (Computer Science). On interaction with a few people on the core
> mentorship mailing list, I have been led to believe that there is some
> code restructuring happening here.

Definitely.

> I request one of you to assign some tasks to me as I'd love to contribute.

Mark Roseman is submitting code faster than I can review it, in addition 
to whatever I write.  So the question is, can you do anything that saves 
me time (or possible him)?

Do you have development setup, hg+repository clone?
   Ie, can you apply, test, and create new patches?
What OS can you use for Python work?
   Patches sometimes need testing on multiple systems.
Which versions (2 versus 3) of Python do you know?
   In particular, can you produce a 2.x version of a patch?
Do you know unittest well, or are you willing to learn it?
   There are proposed test modules sitting on the tracker for review.
What else can you say that might help me assign a task?

> Rohan Ds

As near as I can tell by searching the user list, you do not have a 
tracker account.  Please make one, and sign the contributor agreement.
https://www.python.org/psf/contrib/
https://www.python.org/psf/contrib/contrib-form/

Out of curiosity, what does 'Ds' mean?  Name (short for Das?) or title?

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Thu Sep 24 06:36:27 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 24 Sep 2015 00:36:27 -0400
Subject: [Idle-dev] Proposal: revamp Idle doc 'Syntax Color' section
Message-ID: <mtvukh$dlr$1@ger.gmane.org>

In https://bugs.python.org/issue25225
I propose to rename, demote, condense, and revamp the Syntax Colors 
section of the Idle doc.  The content change would be to drop the 
default color listing, which predates the Highlighting dialog that makes 
it obsolete, and instead better describe what text is being colored.

The last post has the proposed new text.  Any comments before I change 
idle.rst and apply?

-- 
Terry Jan Reedy


From tjreedy at udel.edu  Sat Sep 26 02:17:33 2015
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 25 Sep 2015 20:17:33 -0400
Subject: [Idle-dev] New Idle-Dark theme
Message-ID: <mu4o76$otc$1@ger.gmane.org>

At the request of Mark Roseman and others, I plan to add a new builtin 
dark theme before the May 3 3.4.4rc release.  The current version is 
attached to
https://bugs.python.org/issue24820
It can be tested by adding the content of idle-dark.cfg to a current 
.idlerc/config-highlight.cfg or by downloading that file as such. I may 
add another version before committing.  If you are interested in this, 
please join the issue and test.

-- 
Terry Jan Reedy