[openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible
vstinner at redhat.com
Thu Apr 23 07:10:09 UTC 2015
> 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:
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, exc_info, exc_info" 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.
More information about the OpenStack-dev