On Thu, 19 May 2011 05:42:29 -0700, lkcl wrote: > has anyone considered the idea of literally creating a Python2/ > subdirectory in the python3 codebase, literally just dropping the entire > python2.N code directly into it, renaming all functions and data > structures, adding a "--2-compatible" switch to the python3 argc/ v and > seeing what happens? > > no interoperability, no maintenance, no "compatibility" - just > "support for python 2 directly in the python3 binary".
No maintenance? The code won't maintain itself, people using it won't stop reporting bugs. Are you suggesting that the CPython developers should just grit their teeth and refuse to maintain or support code that is part of the official release? Who is your suggested user-base? Those who want support for 2.7 to continue won't be happy with an unmaintained, unsupported compatibility layer. Those who are happy to keep on using obsolete software won't need this compatibility layer, they can just keep using the Python 2.7 they already have. Or 2.5, or 1.5 if they prefer. (I have 1.5 on my machine, installed from source, and it works perfectly well.) And what of the others? Jython, IronPython, PyPy, Stackless ... once they make the move to Python 3 compatibility, are they expected to implement this compatibility layer as well? I dare say that once the original developers stop supporting Python 2.7 in three or seven(?) years, there will be a good niche for some commercial distribution like ActiveState to continue support. Or one of the many critics who insist that Python 3 is a mistake can put their money where their mouth is and continue support themselves. After all, Python is open source. Somebody (you?) could even fork the code base and implement your suggested compatibility layer, or backport Python 3 features, be really daring and create a 2/3 hybrid. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
