On Thu, Apr 23, 2015 at 12:10 AM, Victor Stinner <vstin...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
