4 ms·

First SciPy release to support Python 3

83 points by andrevoget 16y ago

sigzero 16y 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.
levesque 16y 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 16y 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 16y ago
  Get matplotlib working and I'm there!
  - levesque 16y 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 http://www.ctpug.org.za/wiki/Meeting20110305).
    - jgamman 16y ago
      so you read it... on reddit?
cypherpunks 16y ago
Boo. I hate Python 3. Hate. hate. hate. It's a poorly designed mistake.
- xi 16y ago
  Care to elaborate?
  - sigzero 16y 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.
    - xi 16y ago
      Well, I don't entirely agree here; there are some valid concerns about Py3-specific design decisions. Take, for instance, conversion of `str` to Unicode. That * significantly increases the memory footprint as every character requires 2-4 bytes to encode. * does not provide 1-to-1 correspondence with certain Asian encodings. * creates an impedance mismatch between Python and byte-oriented filesystem/internet protocols. Personally, I believe total Unicodification in Py3 was worthwhile, but from some perspective, it could be seen as a regression. That said, I'd love to hear what specifically in Py3 could cause such a burst of hate.
      - wladimir 16y ago
        Python3 has the 'bytes' type, which can be used for the same things that 'str' was used for in Python 2.x . So you don't lose any functionality, just rename your types. As an added bonus, the name 'bytes' makes it very clear, that you're dealing with raw data. Strings have become a data-type solely for human-readable text. For these, it makes perfect sense to only support unicode.
  - cypherpunks 16y 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.

83 points by andrevoget 16y 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.

levesque 16y 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 16y 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 16y ago
Get matplotlib working and I'm there!
- levesque 16y 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 http://www.ctpug.org.za/wiki/Meeting20110305).
  - jgamman 16y ago
    so you read it... on reddit?

cypherpunks 16y ago

Boo. I hate Python 3. Hate. hate. hate. It's a poorly designed mistake.

xi 16y ago
Care to elaborate?
- sigzero 16y 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.
  - xi 16y ago
    Well, I don't entirely agree here; there are some valid concerns about Py3-specific design decisions. Take, for instance, conversion of `str` to Unicode. That * significantly increases the memory footprint as every character requires 2-4 bytes to encode. * does not provide 1-to-1 correspondence with certain Asian encodings. * creates an impedance mismatch between Python and byte-oriented filesystem/internet protocols. Personally, I believe total Unicodification in Py3 was worthwhile, but from some perspective, it could be seen as a regression. That said, I'd love to hear what specifically in Py3 could cause such a burst of hate.
    - wladimir 16y ago
      Python3 has the 'bytes' type, which can be used for the same things that 'str' was used for in Python 2.x . So you don't lose any functionality, just rename your types. As an added bonus, the name 'bytes' makes it very clear, that you're dealing with raw data. Strings have become a data-type solely for human-readable text. For these, it makes perfect sense to only support unicode.
- cypherpunks 16y 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.