Open Stack

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

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)?

A single week may not be enough to fix all Python 3 issues. I prefer to submit changes smoothly during the Liberty cycle.


> 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