[Python-ideas] Introducing PEP 434 -- IDLE Enhancement Exception for All Branches

Andre Roberge andre.roberge at gmail.com
Thu Feb 21 02:44:33 CET 2013


>From what I have read on edu-sig, I believe it would be a huge mistake to
remove IDLE from the Python standard library.


On Wed, Feb 20, 2013 at 9:41 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 2/20/2013 6:12 PM, Antoine Pitrou wrote:
>
>> On Wed, 20 Feb 2013 17:07:57 -0500
>> Terry Reedy <tjreedy at udel.edu> wrote:
>>
>>>
>>> On the other hand, I agree that a PyPI preview release of a rewrite of
>>> IDLE to use the newer ttk widgets would be a good idea. But I personally
>>> would base such a project on 3.3 and consider whether it should require
>>> tcl/tk 8.6 rather than 8.5. And I would only put it in the stdlib in a
>>> new release (perhaps alongside the existing IDLE for at least one
>>> release). So this PEP is not relevance to such a project.
>>>
>>
>> The only thing relevant to such a project is to find someone actually
>> motivated to do it.
>>
>
> Right. That I what I was trying to say.
>
>  What is IDLE's actual maintenance activity, exactly?
>>
>
> I am not sure whether you are asking about volume or focus. A year ago,
> focus was on bugs that caused IDLE to quit because of an uncaught
> exception. When IDLE is started on Windows from an icon, this looks like a
> crash because there is no visible traceback or exit message. Recently,
> other issues have been worked on. In the last 5 months, activity has picked
> up and there are about 40 issues in 3.4 misc/news whose commit message
> contains 'idle'.
>
> > I am sympathetic to the PEP
>
> Even though I am willing for the PEP to be rejected, great. I say this
> because I think it better for the community at large, even though a strict
> policy might be easier, on net, for developers.
>
>  but, really, thinking IDLE's development is hampered by Python's
>> release process is *completely* ridiculous.
>>
>
> I do not believe I have said that and certainly have not meant to say
> that. What I have said or meant to say is that uncertainly and disagreement
> about how it does and should fit into the release process can be a
> hindrance.
>
> > If you want IDLE development
>
>> to happen, please stop talking and start reviewing / committing patches.
>>
>
> I have, of course, done some of both in the past year, even if not
> currently. As I remember, the review process for at least one issue got
> hung up on whether a (small) change was a 'bugfix' or 'enhancement' and if
> the latter, whether it could go into all versions or just default. As we
> move from obvious bug issue to more ambiguous issues, this question would
> come up more often.
>
>  FTR, I'm personally +1 on yanking IDLE out of 3.4.
>>
>
> That would tend to keep 3.4 out of some classrooms.  See, for example,
> http://search.gmane.org/?**query=&author=Jean-Paul.Roy%**
> 40unice.fr&group=gmane.comp.**python.idle&sort=relevance&**
> DEFAULTOP=and&query=<http://search.gmane.org/?query=&author=Jean-Paul.Roy%40unice.fr&group=gmane.comp.python.idle&sort=relevance&DEFAULTOP=and&query=>
> from a French college teacher. (The issue was fixed by a tk fix last
> March.) But of course, this is a different subject.
>
> --
> Terry Jan Reedy
>
> ______________________________**_________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130220/fc10b9b9/attachment.html>


More information about the Python-ideas mailing list