On Tue, Jun 19, 2018 at 01:05:10PM +0100, Daniel P. Berrangé wrote: [...] > > > > The python-future package would help us write code for a single > > > > file/string API instead of two different APIs, but it's not a > > > > QEMU build dependency (yet?), so this patch is good enough for > > > > now. > > > > > > Please do not invest more than absolutely necessary in Python 2 support. > > > All such investment will turn into technical debt in less than two > > > years. If you must invest, pick a solution that will result in less > > > technical debt. We can accept local ugliness for that. > > > > > > In my personal opinion, dumb ideas like supporting Python 2 this close > > > to its EOL ought to look ugly. > > > > That's the whole point: python-future allows us to not worry > > about Python 2 support in the code anymore because it exposes the > > Python 3 string API (and others) even if we're running Python 2. > > > > After we stop supporting Python 2, we can simply delete the "from > > __future__ import .*" and "from builtins import .*" lines. > > > > Anyway, I will send a RFC series demonstrating that, and then we > > can discuss if it's worth it. My main worry is not the extra > > imports in Python code, but the introduction of a new build > > dependency only for a few (one?) releases. > > Using __future__ doesn't add an build dependancy AFAIK. __future__ is > bundled with core python library rather than being an addon module.
The extra dependency is because of the "builtins" module, provided by python-future in Python 2.7. -- Eduardo
