On Mon, Apr 20, 2015 at 11:14:28AM -0400, Paul Tagliamonte wrote: > So, round one of all of this is getting the critical path *under* each > of our services ready, so that when we need to migrate, we don't need > to scramble. > > As a compromise to keep us both happy - if we were to focus on making > sure the code ran on both Python 2 *and* Python 3, would you be open to > those patches? You could continue the production deployment on Python 2, > and also let some porting work go on to ease that transition later. I > believe this would mostly take the form of a new python-six dependency, > as well as evaluating alteranatives to dead-end Python 2 only support > libraries.
I would be open to patches that make all the dependencies work for both 2 and 3. That is because if it is code that is not in the main repo, it means that it is code that is supposed to be shared, and therefore it should not tie its user to a specific python version. I'm thinking of python-debiancontributors and python-django-housekeeping here, for example. For the sites themselves, it depends. I use dict.iteritems a lot, and I do not intend to see my code migrated to use six.iteritems because it makes code hard to read, and it then requires a furter migration to make it readable again once there is a switch to python3. I can however take a migration to .items() for a temporary performance penalty that will go away without need of extra intervention after a switch to python3. So, patches that make code work in python3 without breaking idiomatic code, good. Patches that turn the code into an intermediate six-based language that looks neither like 2 nor 3, no thanks: that code will have to be maintained afterwards. Also, if I implement new features I am not necessarily going to test them on python3 unless it somehow happens automatically. Running the test suite twice is not much of an option, though, because it already takes a lot of time to run, and doubling the time it takes just means that code is going to get tested less. Unless of course someone reviews my test code and finds a way to make it run super fast: I'd certainly welcome that! This said, contributors.d.o is the simplest of them all, and could be a starting point to all get acquainted and see how it goes. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: Digital signature
