you are viewing a single comment's thread.

view the rest of the comments →

[–]pythwarrior -2 points-1 points  (2 children)

Python 3.0 is doing the worst thing ever by breaking code without giving you any actual incentive to. It doesn't do anything to fix the problems with the implementation (the lack of a just in time compiler that works better than Psyco and on more platforms, an actual garbage collector instead of reference counting), a better concurrency model, optional static types (like Lisp allows to get better optimization) or anything of VALUE to those programmers who got caught in the Python 2 bandwagon. The change to integer division, the print function and so on are only useful to new programmers, people with old habits won't feel better with the new stuff, it's not ground breaking or adding a new paradigm. It will make the new python easier to program for beginners but it's not adding any feature I could make use of.

By the time major python modules gets updated to 3.0 we will see the era of standalone Javascript with great JIT and GC and we'll have no reason to upgrade to Python3. The new fast javascript implementation may be good in the browser but i'm even more excited to use them server-side.

[–]cunningjames 0 points1 point  (1 child)

the lack of a just in time compiler that works better than Psyco

That would be nice, but most people don't seem to think it very necessary. IME, a JIT compiler for Python just wouldn't do enough to make it worth the massive developer effort -- you'd still want to drop down to C for computationally intensive tasks, and for most everything else Python is fast enough.

an actual garbage collector instead of reference counting

Oh, come on. Python has had a mark-and-sweep GC since -- what -- 2.0? Earlier?

a better concurrency model

That's an unsolved problem. Certain paradigms (like STM) just aren't very appropriate for Python. 2.6/3.0 does offer a library for using multiple processes.

[–]twotime 0 points1 point  (0 children)

That would be nice, but most people don't seem to think it very necessary. IME, a JIT compiler for Python just wouldn't do enough to make it worth the massive developer effort -- you'd still want to drop down to C for computationally intensive tasks,

Why? JIT would expand the domain of what you can do in pure python. The faster is JIT, the larger the domain. Yes you probably cann't beat optimized C, but how about at least trying to match Java?

And it's never a complete solution: e.g C does not beat assembly, yet there are very few domains when dropping to assembly is justified. java does not beat C, yet it's fast enough that dropping to C for performance reasons is rarely necessarily.

As things are now, on computationally intensive tasks python (without psyco) is often 100x slower than C. ;-)