[openstack-dev] [swift] Stategy to port Swift to Python 3

Victor Stinner vstinner at redhat.com
Tue Jul 7 10:40:50 UTC 2015


Hi,

I have 9 pending patches to fix Python 3 issues in Swift, but they 
didn't get much attention yet. Most of these patches replace a pattern 
with a new pattern to add Python 3 support in addition to Python 2 support.

https://review.openstack.org/#/q/owner:%22Victor+Stinner%22+status:open+project:openstack/swift,n,z

The problem is that these patches are long, and so it's common to get 
conflicts. It takes me a lot of time just to rebase these patches.
Only "Replace dict.iteritems() with dict.items()" got a +2 yet.

I hesitate to simply give up on porting Swift to Python 3, to focus on 
other projects which are faster to review my Python 3 patches 
(ceilometer, cinder, glance, keystone, nova).

Maybe I took the wrong strategy for Swift. Instead of replacing a 
pattern in the whole Swift project, I should maybe try to port tests one 
by one to have shorter patches?

My last try fix "tox -e py34" in a single patch:
https://review.openstack.org/#/c/199034/

Practical issue: it depends on my pyeclib pull request that I sent 3 
months ago...

If this Swift "Fix tox -e py34" patch is merged, my pyeclib pull request 
is merged, and a new version of pyeclib including my fix is released, it 
will become possible to make the gate-swift-python34 voting to avoid 
Python 3 regressions. It should be nice milestone to start with shorter 
patches.

What do you think?

Victor



More information about the OpenStack-dev mailing list