Showing content from http://mail.python.org/pipermail/python-dev/attachments/20100507/a267a833/attachment-0001.html below:
<br><br><div class="gmail_quote">On Fri, May 7, 2010 at 09:09, A.M. Kuchling <span dir="ltr"><<a href="mailto:amk@amk.ca">amk@amk.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:<br>
> 3.x). I'll take a stab at a more accurate rationale:<br>
<br>
</div>Thanks! Â I've applied the scalpel and reduced it to:<br>
<br>
* A policy decision was made to silence warnings only of interest to<br>
 developers by default.  :exc:`DeprecationWarning` and its<br>
 descendants are now ignored unless otherwise requested, preventing<br>
<div class="im"> Â users from seeing warnings triggered by an application. Â (Carried<br>
 out in :issue:`7319`.)<br>
<br>
</div> Â In previous releases, :exc:`DeprecationWarning` messages were<br>
 enabled by default, providing Python developers with a clear<br>
 indication of where their code may break in a future major version<br>
 of Python.<br>
<br>
 However, there are increasingly many users of Python-based<br>
 applications who are not directly involved in the development of<br>
 those applications.  :exc:`DeprecationWarning` messages are<br>
 irrelevant to such users, making them worry about an application<br>
 that's actually working correctly and burdening the developers of<br>
 these applications with responding to these concerns.<br>
<br>
 You can re-enable display of :exc:`DeprecationWarning` messages by<br>
<div class="im"> Â running Python with the :option:`-Wdefault` (short form:<br>
 :option:`-Wd`) switch, or you can add<br>
 ``warnings.simplefilter('default')`` to your code.<br>
<br></div></blockquote><div><br></div><div>That sounds good to me.</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
</div>Benjamin suggested being very definite about a 5-year maintenance<br>
period, but I don't want to write any checks our butt can't cash, so<br>
I've left the text as "Maintenance releases for Python 2.7 will<br>
probably be made for 5 years." Â An alternative formulation might say<br>
it will be maintained for the next two 3.x releases, not the next one<br>
as usual.<br>
<br>
I thought about Ben Finney's suggestion to not give a timespan and<br>
describe the conditions for 2.x maintenance continuing, but those<br>
conditions are complicated to describe -- if 3.x doesn't catch on? Â if<br>
the 3.x transition is slow? Â if there's a significant 2.x user base<br>
that remains? Â if someone starts a 2.x maintenance team? -- and might<br>
be a confusing tangle of what-if statements.</blockquote><div><br></div><div>Why can't we simply say that "we plan to support Python 2.7 beyond the typical two years for bugfix releases"? It doesn't tie us to anything but still lets people know our intentions. We don't have to worry about every possible scenario now (e.g. 3.x gets no more traction or some other rare event) and saying we plan on long term support but don't know for how long is completely truthful; we have no timeline on how long we are willing to keep 2.7 afloat beyond the fact that we plan to do it longer than normal.</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