On Jul 24, 2013, at 1:12 PM, Chuck Short <chuck.sh...@canonical.com<mailto:chuck.sh...@canonical.com>> wrote:
Hi, The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites in the Openstack project is quite extensive. This is probably due to the fact that it is the most familiar mocking object framework for most python developers. However there is big drawback with using mox across all of the OpenStack projects is that it is not python3 compatible. This makes python3 compliance problematic because we want the test suites to be compatible as well. While thinking about this problem for a while now, while helping porting OpenStack over to python3 there is a couple of options that as a project can do as a whole: 1. Change mox usage to more python3 friendly such as mock. (https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code churn in the projects as we move away from mox to mock. 2. Use the python3 fork called pymox (https://github.com/emonty/pymox). This project has reasonable compatibility with mox and is python3 compatible. Using this option causes less code churn. IMHO this would be the better option. I would like to hear peoples opinion on this. Moving towards the standard library's unittest.mock for 3 and the external package for 2 is what I've done in the past, but I moved away from mocker and another one I forget, not mox. Are there usages of mox that aren't served by mock? Code churn sucks, but if something has to change, I think there's value in moving toward the standard facilities if they'll do the job.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
