

First SciPy release to support Python 3 - andrevoget
http://sourceforge.net/projects/scipy/files/scipy/0.9.0/

======
levesque
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.

~~~
rflrob
Get matplotlib working and I'm there!

~~~
levesque
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>).

~~~
jgamman
so you read it... on reddit?

------
sigzero
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.

------
cypherpunks
Boo. I hate Python 3. Hate. hate. hate.

It's a poorly designed mistake.

~~~
xi
Care to elaborate?

~~~
cypherpunks
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.

~~~
xi
While each of your individual complains may make sense, as a whole, they are
amusingly self-contradictory.

You start with arguing for groundbreaking changes in the semantics and
internal API, which practically render every single binary extension obsolete.
Then you complain about minor semantics changes that forced you to do simple
mechanical conversion.

Don't you think C extension authors would be equally or even more upset at
having to rewrite their extensions from scratch? 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).

Concerning your individual complaints.

 _It makes no effort to move towards the multicore era -- very minor changes
would make the language potentially scale much better._

"Very minor changes"? I seriously doubt it. Besides, I'm sure you didn't miss
the announcement: we are already in the "cloud" era. ;)

 _Print syntax changed._

It was probably done to remove two ugly special forms:

    
    
      print foo,
      print >>file, foo
    

_You no longer have the same kind of tuple expansion in function calls._

Doesn't strike me as a good example. It was a problem both for introspection
tools and C API, it was discouraged for a long time and hardly in use. I can't
believe there's a single tear shed for the loss of it.

 _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._

That's what `make altinstall` is for, which is thoroughly documented in the
section "Installing multiple versions" of README. If somebody doesn't read
installation instructions, perhaps it's their fault after all?

 _"very hard to optimize", "very minor changes", "seriously broken"_

Seriously, it's not very specific. A lot of heat, not enough sense.

~~~
cypherpunks
> 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.

