Resetting PHP 6

Posted Mar 24, 2010 17:40 UTC (Wed) by drag (guest, #31333)
In reply to: Resetting PHP 6 by cdamian
Parent article: Resetting PHP 6

Adoption of new python releases have always been slow. I'm using Python 2.5 mostly since that is what is used in Debian unstable by default right now. Python2.6 was first released in 2008.

Of course Python2.6 and Python3 are avialable. I just try to write things so as to minimize the effort it takes to port it to newer versions, which for me is acceptable since none of it is really very complex. Larger projects are going to have larger problems, of course.

The big difference between Perl 6, PHP 6, and Python3 is that Python3 is out right now, avialable, has a bunch of transition tools, code is somewhat backwards compatible to 2.6, and it's had a couple stablizing releases.

Also it's not just about the Unicode support... Strings in Python 2.x were heavily overloaded and used for _everything_...(the major alternative being using Array module, which is a wrapper around C arrays, which end up being slower for most things then native python data types) Being forced to use data encoded into ASCII strings for everything has grown quite painful. Especially since every year less and less of your data is actually going to be stored in ASCII strings! It's all UTF-8 or binary. Having _all_ strings be unicode while introducing the byte data type is a godsend for a lot of things I need python for. Keeps things simple, clean and fast.

Backwards compatibility

Posted Mar 27, 2010 22:53 UTC (Sat) by man_ls (guest, #15091) [Link]

The big difference between Perl 6, PHP 6, and Python3 is that Python3 is out right now, avialable, has a bunch of transition tools, code is somewhat backwards compatible to 2.6, and it's had a couple stablizing releases.

But "somewhat backwards compatible" is not good enough. For any non-trivial applications you still need to test everything again, and probably do some coding + testing + deploying. In business settings it translates to money and pains; in volunteer projects just pains.

Even when backwards compatibility is a requirement, like for Java (where the rare breakages are clearly signaled and known by everyone), testing time for new versions has to be allocated. With Python migrations are a showstopper for most people unless the new version somehow provides great advantages (which for me it doesn't). For developers of the language itself and the runtime, the supposed benefits of not having to be backwards compatible are probably offset by having to support two or three versions indefinitely.