RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20130320/9cecad30/attachment.html below:

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson <span dir="ltr"><<a href="mailto:benjamin@python.org" target="_blank">benjamin@python.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/3/20 Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>>:<br>

<div class="im">> On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote:<br>
><br>
>>IDLE would be a great first foray into this "separate project" world,<br>
>>because it is many ways a separate project.<br>
><br>
> I really think that's true. A separate project, occasionally sync'd back into<br>
> the stdlib by a core dev seems like the right way to manage IDLE.<br>
<br>
</div>I would advise against this. Basically, every "externally-maintained"<br>
package with have causes pain. For example, the stdlib now has some<br>
long-diverged fork of simplejson. With xml.etree, it was not clear for<br>
years whether core developers could touch it even though the external<br>
project had died. Either the stdlib and IDLE should go separate ways<br>
or development has to happen in the stdlib with CPython release<br>
schedule and policies.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Agreed that the "sync into stdlib" think should not happen, or should at best be a temporary measure until we can remove idle from the source tarball (maybe at the 3.4 release, otherwise at 3.5). <br>

</div></div><br></div><div class="gmail_extra">The main thing I like about the separate project idea is that, given that only a small group of people care about IDLE, it is much more satisfying for them to be able to release IDLE separately to their user community regularly (every month if they want to) rather than being held to the core Python release schedule and practices. We should deal with compatibility obligations of the stdlib in the usual way, though maybe we can just delete it in 3.4, since few people presumably use idlelib apart from IDLE itself. Binary distributions from <a href="http://python.org">python.org</a> should still include IDLE (and Tcl/Tk) -- however we should switch to bundling the separate project's output rather than bundling the increasingly broken version in the stdlib. What other distributors do is outside our control, but we ought to recommend them to do the same.<br clear="all">

</div><div class="gmail_extra"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)

</div></div>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4