4 ms·
I don't think backwards compatibility is the problem. The problem with Py3k is that it does not offer any vital features, it requires a lot work to port to Py3k
by amix 17y ago
I don't think backwards compatibility is the problem. The problem with Py3k is that it does not offer any vital features, it requires a lot work to port to Py3k (to top that off Py3k is slower than Python 2.x).
The only way I can see Py3k successful is if there are clear advantages to move to Py3k, like improved performance or extra vital features (like improvement of inline functions (lambda)). The improved performance is also a big question as teams like PyPy and Unladen Swallow are working on improving Python 2.6 and not Python3k.
- eru 17y ago> extra vital features (like improvement of inline functions (lambda)) I would not consider this a vital feature. You can already nest arbitrary functions, you just have to name them. However Tail-Call-Optimization would be a vital feature. (Alas, it's not going to happen.)
- masklinn 17y agoI'm pretty sure the improvement he was talking about is "full" anonymous functions (w/ multiple statements & everything).
- scott_s 17y agoAnd I'm pretty sure eru understood that, which is why he pointed out you can achieve the same functionality by naming them.
- eru 17y agoYes. And if you want multiple statements, you are either doing site-effects (evil) or using variables inside your closure, so you might as well name it, too.
- masklinn 17y ago> you are either doing site-effects (evil) Uh not necessarily, and even if you are there are many situations where it's interesting and useful. > or using variables inside your closure, so you might as well name it, too Does not follow.
- jnoller 17y agoHow about this one: 2.x is dead. While bug fixes and minor changes are occuring, it's going to slip into maintenance mode once 2.7 comes out. All the cool things, such as importlib and other items are py3k only.
- amix 17y agoHow is 2.x dead? Everyone in the Python community is using and developing for 2.x. If you develop for Py3k, then you loose backward compatibility and you can't use upcoming optimizations like Unladen Swallow. I think Python might end up in a situation like PHP4 and PHP5 - where tons of people still use PHP4, even if PHP5 holds tons of improvements and is around 5 years old. Breaking backward compatibility to fix some essential things is an ok move, but I think it's only going to work if Python3k has a much better offering than it currently has.
- scott_s 17y agoIt's not a language, but look at the Linux kernel. The jump from 2.4 to 2.6 was significant - programs that took advantage of some of the added support in 2.6 couldn't run on 2.4 kernels. 2.4 was maintained because many people used it, but eventually all new development started occurring in 2.6 Now 2.6 is the default. I hope Python will go through the same process. It's not that Python 2.x is dead, but that we've scheduled its retirement.
- masklinn 17y ago> programs that took advantage of some of the added support in 2.6 couldn't run on 2.4 kernels. yeah but programs which ran on 2.4 kernels still run on 2.6 right? So the situation is totally different.
- scott_s 17y ago"Totally different," no. Not exactly the same, yes. Similar enough to make a meaningful comparison? I think so.
- 17y ago