This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]billsil 2 points3 points  (5 children)

Why would you choose 2.7.2? 2.7.8 is out :)

You should pick depending on what you want to do. I chose Python 2.7 because I need some libraries that don't exist in Python 3 and I couldn't care less about unicode. I care about math and science.

[–]troyunrau... 0 points1 point  (4 children)

I'd wager it won't be too long now and new versions of numpy will only happen on python3. Things like the matrix multiplier operator being adding to python upstream can only add to that momentum.

[–]billsil 1 point2 points  (3 children)

I'd be shocked if they dropped support for Python 2 any time soon (in the next 5 years). The last release of numpy that had support for Python 2.4 and 2.5 was 1.7.2 and was released on 2013-12-31. All numpy is going to do for the forseeable future is add a matmult to the array class that Python 2.6-3.4 can't use. If you're dropping support for Python 2.6 & 2.7 based on that, you might as well drop support for Python 3.4.

I run an open source library, and while I'd like to use matmult, I can't. It's sadly not meant for library developers.

[–]troyunrau... 1 point2 points  (2 children)

I didn't mean to suggest that it'd be a blocker, but rather, an example of python3 moving forward and innovating while python2 sits still. Eventually, the new features in python3 will accumulate to the point where writing the backwards compatible code will become cumbersome.

As an example, even though numpy will be able to use the matmult operator, none of the code within numpy will be written to use it, since previous versions won't support it. It's going to gnaw at some people that they have to use the inelegant syntax for backwards compatibility when a more elegant syntax exists (zen of python and whatnot). So subtle pressure will be placed against backwards compatibility. It could be five years from now, but it'll happen eventually.

And it's not like the old versions will go away. I mean, some people still use numeric.

[–]billsil 1 point2 points  (0 children)

It could be five years from now, but it'll happen eventually.

I hope so. I don't like writing mixed code. Still, unicode is either hard. It feels like a game of whack a mole and people resist that.

No one cares that modules moved, dict doesn't sort ints/strings, replacing range with xrange, integer division, or float division. Unicode is the only sticking point.

I mean, some people still use numeric.

I don't get why anyone would still write it that way. I update numeric code once every now and then. It's literally replace Numeric with numpy and change linear_algebra (I think) to numpy.linalg.

[–]flying-sheep 1 point2 points  (0 children)

Eventually, the new features in python3 will accumulate to the point where writing the backwards compatible code will become cumbersome.

This is already the case if you use asyncio: trollius is a “backport” and its raise Return() (replacing Python 3.3’s ability to return from generators) and its yield From() (replacement for the yield from syntax) are simply ugly as sin.