Open Stack

On Thu, Apr 23, 2015 at 12:10 AM, Victor Stinner <vstinner at redhat.com>
wrote:

> Hi,
>
> > How invasive would the port to python3 be?
>
> I squashed all my commits into a single commit of my draft port and I
> pushed it at:
>
> https://github.com/haypo/nova/commit/bad54bc2b278c7c7cb7fa6cc73d03c70138bd89d


I like how the sha1 starts with 'bad'

Overall that is a pretty small patch.


>
> As announced, changes are boring, just obvious Python2/Python3 issues:
>
> - strip L from long integer literals: 123L => 123
> - replace dict.iteritems() with six.iteritems(dict)
> - replace list.sort(cmp_func) with list.sort(key=key_func)
> - replace "raise exc_info[0], exc_info[1], exc_info[2]" with
> six.reraise(*exc_info)
> - moved functions / modules
>
>   * get http.client, urllib.request and other stdlib modules from
> six.moves since they moved between Python 2 and Python 3
>   * get itertools.izip/zip_longest from six.moves
>   * replace unichr() with six.unichr()
>
> - replace filter(func, data) with [item for item in data if func(item)]
> - replace unicode() with six.text_type
> - replace (int, long) with six.integer_types
> - replace file() with open()
> - replace StringIO() with six.StringIO()
>
> These changes are not enough to port nova to Python 3. But they are
> required to be able to find next Python 3 bugs.
>
> Reminder: Python 2 compatibility is kept! There is not reason right now to
> drop Python 2 support, it would be a pain to upgrade!
>
>
> > 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?
>
> Do you mean a physical meeting? Or focus on Python 3 during a short period
> (review/merge all Python 3 patches)?
>
>
Focus on Python 3 during a short period.


> A single week may not be enough to fix all Python 3 issues. I prefer to
> submit changes smoothly during the Liberty cycle.
>
>
>
My general concern, is having to manually review new code for python3
compliance.

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.

> In general what is the least painful way to add python3 support for a
> very large python project?
>
> Send patches and make incremental changes, as any other change made in
> OpenStack.
>
> Victor
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150423/62f37db6/attachment.html>