| > While each of your individual complains may make sense, as a whole, they are amusingly self-contradictory. I don't think they are. My basic take is that you break compatibility only when you really, really have to, and when it buys something significant. I don't see anything significant that Python 3 buys. I see a bunch of minor changes and tweaks to syntax, some of which are arguably better, and some of which are arguably worse. It's annoying and pointless. We'll have a split community for a decade so that print syntax can be slightly more consistent. Many corporate projects will just never move. On the other hand, it misses the whole multicore/GPGPU era coming up. > Even with the minimal incompatibilities on the C API level, it took ~2 years to port numpy/scipy, do you believe it would have ever happened if the changes you advocate for were introduced? Well, had the scope of Python 3 included removal of GIL and a JIT compiler, I doubt we had a single release yet while the usage of Python 2.x would be on decline (see the sad story of Perl 6). Perl 6's problem is that it is not released. It's a research project in language design. Larrry didn't design a target for what he was building, and so it had feature creep, and never shipped. It's got bits and pieces, but even now, it is unfinished. If Perl 6 had been the same language, but designed and shipped quickly, I doubt you would see the same problems (especially given source-level backwards compatibility -- Perl 6 can load Perl 5 modules). Here, virtually all the development could be done incrementally, with a target design spec (we have models for changes from existing languages like Fortress), and in parallel in Python 2 and 3. I think it would be very possible to bound it in scope. With regards to SciPy, Numpy, the answer is a resounding hell yes. Right now, the only reason they have for porting to Python 3 is because somebody tells them it is the future. The major problem with Numpy/Scipy for a very large number of users is speed. It is at least an order of magnitude slower than C. If a Python 3 port allowed me to write: d=[(cos(x), sin(y)) for (x,y) in d] And Python 3 could either JiT this to run at C speed, or better yet, fork it out to the GPU, I can assure you the porting process would be Numpy's/Scipy's top priority. > If somebody doesn't read installation instructions, perhaps it's their fault after all? Not when it's the recommended way of doing it to the point where distributions do it. Right now, you've got a situation where end-users have system installs where Python programs just don't work. > Seriously, it's not very specific. A lot of heat, not enough sense Because each of those is an essay, and was beaten to death elsewhere. See the Reddit articles, LWN articles, etc. |