First SciPy release to support Python 3

http://sourceforge.net/projects/scipy/files/scipy/0.9.0/

by andrevoget • 15 years ago

83 14 15 years ago

sigzero2• 15 years ago

CherryPy too. I think the wave of updates might be starting (a little bit at least). I know the larger projects are at least talking about going to P3. So I take this all as a good sign.

levesque2• 15 years ago

This is awesome. scipy and numpy are my main dependencies, they were pretty much the only reason I was not moving to Python 3 yet.

almost• 15 years ago

Me too! SciPy has been my main reason for not switching for a lot of work I do. I'll see if I can switch soon now :) I just need Django to work and I'll be set to completely leave 2.x behind!

rflrob• 15 years ago

Get matplotlib working and I'm there!

levesque2• 15 years ago

I read on reddit that they are working on it. They will actually do a code rush to release a Python 3 enabled version next weekend (http://www.ctpug.org.za/wiki/Meeting20110305).

cypherpunks3• 15 years ago

Boo. I hate Python 3. Hate. hate. hate.

It's a poorly designed mistake.

xi3• 15 years ago

Care to elaborate?

sigzero2• 15 years ago

I would be interested too but I think there is no answer. It is incorrect. P3 corrects a lot of things from P2. I doubt you could support "poorly designed" unless you are talking about Python as a whole.

cypherpunks3• 15 years ago

Sure. It doesn't fix the core problems. Global Interpreter Lock is still there. The semantic issues that make it very hard to optimize JiT are still there. It makes no effort to move towards the multicore era -- very minor changes would make the language potentially scale much better. Still no tail recursion. The C API still locks you into a bunch of non-scalable data structures. Those are the kinds of improvements worth breaking backwards-compatibility for.

On the other hand, it makes a bunch of syntax tweaks that don't make things much better, but break backwards compatibility. You no longer have the same kind of tuple expansion in function calls. Why? No good reason. Print syntax changed. It's a little more consistent, and a little less readable. Better? Maybe, maybe not. Just an arbitrary little change. Personally, I would have just made subroutines (in addition to functions) language constructs. C-style string formatting was deprecated. Why not just leave it around? It wasn't causing any harm.

Iterators replace lists. I can see why you'd want the performance -- but the way it is done makes the language a lot more complex for newbies. It also breaks backwards-compatibility. In many places, the break is arbitrary, capricious, and just lazy. E.g. .sort() no longer works. It'd be easy to make a .sort() that changes object type and just works. Instead, you need to make tweaks in thousands of lines of code to go to sorted().

And for each speedup, you've got a slowdown. Ints are now infinite precision. I think the old way (no iterators, normal ints) was probably both faster and more readable than the new one (iterators, long ints), but hey. We gotta swap things around. The old way is just so... old.

It's nice to have Unicode, but the way Unicode is implemented is seriously broken. You run into deep issues dealing with files. It's also seriously not backwards-compatible. It'd be easy to come up with schemes that are only a little not backwards-compatible.

Oh. And just to be ass-backwards, we'll call the executable "python" just like in Python 2. If you install Python 3, and scripts begin with #!/usr/bin/python, suddenly your system breaks.

I could keep going for a while, but personally, I prefer Python 2 to Python 3. Python 3 doesn't fix many things that were wrong (printing of floating points being the exception), but seriously breaks backwards compatibility. Most of the changes are just that -- changes, and not improvements. You can make an equally plausible argument that the old way was better. I fail to see the point.

First SciPy release to support Python 3

Related Stories