<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 12:10 AM, Victor Stinner <span dir="ltr"><<a href="mailto:vstinner@redhat.com" target="_blank">vstinner@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
> How invasive would the port to python3 be?<br>
<br>
</span>I squashed all my commits into a single commit of my draft port and I pushed it at:<br>
<a href="https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70138bd89d" target="_blank">https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70138bd89d</a></blockquote><div><br></div><div>I like how the sha1 starts with 'bad'</div><div> </div><div>Overall that is a pretty small patch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
As announced, changes are boring, just obvious Python2/Python3 issues:<br>
<br>
- strip L from long integer literals: 123L => 123<br>
- replace dict.iteritems() with six.iteritems(dict)<br>
- replace list.sort(cmp_func) with list.sort(key=key_func)<br>
- replace "raise exc_info[0], exc_info[1], exc_info[2]" with six.reraise(*exc_info)<br>
- moved functions / modules<br>
<br>
  * get http.client, urllib.request and other stdlib modules from six.moves since they moved between Python 2 and Python 3<br>
  * get itertools.izip/zip_longest from six.moves<br>
  * replace unichr() with six.unichr()<br>
<br>
- replace filter(func, data) with [item for item in data if func(item)]<br>
- replace unicode() with six.text_type<br>
- replace (int, long) with six.integer_types<br>
- replace file() with open()<br>
- replace StringIO() with six.StringIO()<br>
<br>
These changes are not enough to port nova to Python 3. But they are required to be able to find next Python 3 bugs.<br>
<br>
Reminder: Python 2 compatibility is kept! There is not reason right now to drop Python 2 support, it would be a pain to upgrade!<br>
<span class=""><br>
<br>
> Would it be easier to have a python3 migration sprint and rip the band aid off instead of dragging it out and having partial python3 support for a whole cycle?<br>
<br>
</span>Do you mean a physical meeting? Or focus on Python 3 during a short period (review/merge all Python 3 patches)?<br>
<br></blockquote><div><br></div><div>Focus on Python 3 during a short period.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A single week may not be enough to fix all Python 3 issues. I prefer to submit changes smoothly during the Liberty cycle.<br>
<span class=""><br>
<br></span></blockquote><div><br></div><div>My general concern, is having to manually review new code for python3 compliance.</div><div><br></div><div>If this will take more then a week or two to make a big project python3 compat (during a virtual sprint), it would be good to have some tooling in place to make sure we don't add a lot more burden on reviewers to make sure new patches are python3 compatible by hand.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> In general what is the least painful way to add python3 support for a very large python project?<br>
<br>
</span>Send patches and make incremental changes, as any other change made in OpenStack.<br>
<div class="HOEnZb"><div class="h5"><br>
Victor<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>