rusi <rustompm...@gmail.com> writes: > Costs can be single-cased (s) -- basically those that can be handled > by a 2to3 module
You can't really 2to3 a large python application and expect to then just start using it without further attention or testing. You may have to do a fairly complete (i.e. expensive) QA and qualification cycle on the 2to3 output, depending on the application and your environment. It's easier to just keep running python 2 for older programs even if you're using python 3 for newer ones. > IOW the irony: the success of python (large n) implies the failure of > py3k... Of course not so ironic if one considers that Fortran, Cobol, > C cant be changed precisely because they are so successful But those languages do change. We just got a new C11 standard, for example. And the more radical change to C was of course C++, which went off in its own direction. IMHO the main weakness of py3 is that its benefits over py2 are rather slight. I've been involved in several newly started python projects in the past few years and they use py2 because what's the point of dealing with brokenness if you're used to something that works and where the gain from switching is insignificant? Py3 would enjoy a lot more success in my opinion, if it broke py2 much more drastically than it does, but delivered larger gains. I guess maybe that can happen with py4. -- http://mail.python.org/mailman/listinfo/python-list
