<br><br>On Thursday, April 26, 2018, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In pondering our approach to future Python major releases, I found<br>
myself considering the experience we've had with Python 3.  The whole<br>
Py3k effort predates my involvement in the community so I missed a<br>
bunch of context about the motivations, decisions, and challenges.<br>
While I've pieced some of that together over the years now since I've<br>
been around, I've certainly seen much of the aftermath.  For me, at<br>
least, it would be helpful to have a bit more insight into the<br>
history. :)<br>
<br>
With that in mind, it would be worth having an informational PEP with<br>
an authoritative retrospective on the lessons learned from the Python<br>
3 effort (and transition).  Consider it a sort of autobiography,<br>
"memoirs on the python-dev change to Python 3". :)  At this point the<br>
transition has settled in enough that we should be able to present a<br>
relatively objective (and consistent) view, while we're not so far<br>
removed that we've forgotten anything important. :)  If such a<br>
document already exists then I'd love a pointer to it.<br>
<br>
The document would benefit (among others):<br>
<br>
* python-dev (by giving us a clear viewpoint to inform decisions about<br>
future releases)<br>
* new-comers to Python that want more insight into the language<br>
* folks transitioning from 2 to 3<br>
* communities that have (or think they have) problems similar to those<br>
we faced in Python 2<br>
<br>
The PEP doesn't even have to be done all at once, nor by one person.<br>
In fact, there are many viewpoints that would add value to the<br>
document.  Hence it would probably make sense to encourage broad<br>
participation and then have a single editor to effect a single voice<br>
in the document.<br>
<br>
The contents of the retrospective document should probably cover a<br>
broad range of topics, since there's so much to learn from the move to<br>
Python 3.  To give an indication of what I mean, I've included a rough<br>
outline at the bottom of this message.<br>
<br>
So...I typically strongly avoid making proposals that I'm not willing<br>
to execute.  However, in this case I simply do not have enough<br>
experience in the history to feel comfortable doing a good job of it<br>
in a reasonable amount of time (which matters due to the tendency of<br>
valuable info to fade away). :/  I have no expectation that someone<br>
will pick this up, though I do hope since the benefit would be<br>
significant.  My apologies in advance if this wasted anyone's time.<br>
<br>
-eric<br>
<br>
<br>
++++++++++++++++++++++++++++++<wbr>++<br>
<br>
I'd hope to see something along the lines of (at least) the following,<br>
in rough order:<br>
<br>
* a concise summary of the document at the top (very meta, I know :) )<br>
  + what were we solving?<br>
  + what was the solution?<br>
  + why do it that way?<br>
  + what went right?<br>
  + what went wrong?<br>
  + impact on the community<br>
  + impact on core dev contribution<br>
* timeline<br>
* key players (and level of involvement)<br>
  + old guard core devs<br>
  + new guard<br>
  + folks brought on for Py3k (e.g. IIRC a swarm of Googlers dove in)<br>
  + non-core-devs<br>
* motivations<br>
* expectations (e.g. time frames, community reaction)<br>
* corresponding results<br>
* a summary of what we did</blockquote><div><br></div><div>nine has a very concise, if incomplete in comparison to six and 2to3, code/namespace/functional summary:</div><div><a href="https://github.com/nandoflorestan/nine/blob/master/nine/__init__.py">https://github.com/nandoflorestan/nine/blob/master/nine/__init__.py</a><br></div><div><br></div><div><a href="https://github.com/benjaminp/six/blob/master/six.py">https://github.com/benjaminp/six/blob/master/six.py</a><br></div><div><br></div><div><div><a href="http://python-future.org/overview.html#automatic-conversion-to-py2-3-compatible-code">http://python-future.org/overview.html#automatic-conversion-to-py2-3-compatible-code</a></div><div><br></div><div>> python-future comes with two scripts called futurize and pasteurize to aid in making Python 2 code or Python 3 code compatible with both platforms (Py2/3). It is based on 2to3 and uses fixers from lib2to3, lib3to2, and python-modernize, as well as custom fixers</div></div><div><br></div><div><div>"Cheat Sheet: Writing Python 2-3 compatible code"</div><div><a href="http://python-future.org/compatible_idioms.html">http://python-future.org/compatible_idioms.html</a></div></div><div><br></div><div><a href="https://github.com/PythonCharmers/python-future">https://github.com/PythonCharmers/python-future</a><br></div><div><br></div><div>> It provides future and past packages with backports and forward ports of features from Python 3 and 2.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* alternative approaches</blockquote><div><br></div><div>#!/usr/bin/env python</div><div># ~~✓pythonver: > 3.3✓~~</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* what went right (and was it on purpose :) )<br>
* what went wrong (e.g. io) and why<br>
* how the Py3k project differed from normal python-dev workflow (e.g.<br>
pace, decision-making, communications)<br>
* lasting impact of python-dev<br>
* key things that would have been better if done differently<br>
* key decisions/planning (mostly a priori to the release work)<br>
  + scope of backward compatibility<br>
  + process (using PEPs with PEPs 30xx guiding)<br>
  + schedule<br>
  + specific changes (i.e. PEPs 31xx)<br>
  + what was left out (and why)<br>
  + plans to help library and app authors transition (e.g. 2to3)<br>
  + feature/schedule overlap with Python 2 (i.e. 2.6 and 2.7)<br>
  + the language moratorium<br>
* things that got missed and why<br>
  + unicode/bytes in some stdlib modules (and builtins?)<br>
* things that were overdone (and how that got missed)<br>
  + unicode/bytes in some stdlib modules (and builtins?)<br>
* (last but not least) challenges faced by folks working to transition<br>
their exiting code to Python 3<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>wes.turner%40gmail.com</a><br>
</blockquote>