Ron Adam wrote: >Maybe "input" can be depreciated in 2.x with a messages to use >eval(raw_input()) >instead. That would limit some of the confusion. > > >
Let me take this opportunity to articulate a principle that I hope this group will adopt, "Thou shalt not muck-up Py2.x in the name of Py3k." Given that Py3k will not be backwards compatible in many ways, we may expect that tons of code will remain in the 2.x world and it behooves us not to burden that massive codebase with Py3k oriented deprecations, warnings, etc. It's okay to backport compatible feature additions and I expect that a number of people will author third-party transition tools, but let's not gum-up the current, wildly successful strain of Python. Expect that 2.x will continue to live side-by-side with Py3k for a long time. It is a bit premature to read the will and auction-off the estate ;-) Any ideas for Py3k that are part of the natural evolution of the 2.x series can of course be done in parallel, but each 2.x proposal needs to be evaluated on its own merits. IOW, "limiting 2.x vs 3k confusion" is NOT a sufficient reason to change 2.x. Raymond _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
