On Jun 09 2016, Carl Meyer <carl-faUO1KlGllLR7s880joybQ@public.gmane.org> wrote:
On 06/09/2016 04:20 PM, Nick Coghlan wrote:
On 8 June 2016 at 00:34, Pavol Lisy <pavol.lisy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
2016-06-05 7:14 GMT+02:00, Nick Coghlan <ncoghlan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
Red Hat's Python maintenance team are working on a more explicitly minimalistic porting guide based on their experiences porting Fedora components, sometimes in the context of upstream projects that are more interested in keeping Python 2.4 support than they are in Python 3: http://portingguide.readthedocs.io/en/latest/
do you have some drafts how to write (new) code supporting python from 2.4 - 2.7 with intention to port it to python3 in future?
Unfortunately, the only practical solution we've found for that case is to fork the code base until the maintainers of the original project are willing to raise the minimum version requirement to Python 2.6: http://portingguide.readthedocs.io/en/latest/process.html#drop-python-2-5-an...
While it's theoretically possible to support 2.4+ and 3.x in the same code base, it's painful in practice due to the lack of the forward compatibility features added in Python 2.6 (such as the Python 3 style syntax for name binding in except clauses)
While I agree that it's by far the best option to raise the minimum supported version to 2.6 (or even 2.7) before trying to straddle to 3, we shouldn't make it sound impossible to straddle all the way back to 2.4. It's painful, for sure, but every issue is surmountable if you're dedicated enough.
Sure, e.g. you could implement a Python 3 runtime in Python 2.4. It's Turing-complete after all. SCNR. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«