4 ms·

I'm SO glad that the core of the python scientific computing development has many of the same apprehensions as I do. This panel was interesting also in that ev

by craigyk 15y ago

I'm SO glad that the core of the python scientific computing development has many of the same apprehensions as I do. This panel was interesting also in that everyone was not so subtly beating around the Python 3K, why? bush. I would have been more direct: 1. pick a single implementation, my choice is PyPy, the performance difference is just too compelling, drop CPython. A lot of the hand-wringing regarding implementing new language features because it would cause a 'few percent' speed cost would be a lot more negligible. 2. if python 3k is going to be non-backwards compatible, then take the opportunity to put a lot more 'carrots' in there. There a lot of good language features/design choices that can still be 'stolen' from other languages. Python could really use more flexible function declaration, ideally something flexible enough that you could simulate creating new keywords, then you don't have to worry about hardcoding new operators with hooks into object methods. 3. have the scientific community start switching to a different language/platform. There are quite a few now that, IMO, are as nice or nicer than python, and have a lot more support behind them (V8?)

lloeki 15y ago
> put a lot more 'carrots' in there Carrots are definitely coming in Python 3.3 and up, whereas 2.6/2.7 and 3.0, 3.1, 3.2 were intended to have some overlap to ease porting.
driax 15y ago
Concerning your 1st point. While it certainly whould be nice to forget CPython and focus on PyPy, I don't think that really is an optional for the forseeable future. CPython is written in very cross-platform portable C, and supports a lot of different systems, among others IBM Mainframes. It would take a long time before PyPy gets that kind of support. PyPy is also a very different kind of implementation. I haven't heard much about any projects that have embedded it inside of an bigger application with great success. A common use of CPython. PyPy still have a long startup time. And it takes a while for the code to by optimized. The last point is something that will not change. Python is used for a lot of small scripts, and even bigger projects such as Mercurial, where PyPy will have a tough chance, if any.
- craigyk 15y ago
  True, good points, but not insurmountable roadblocks, especially if more weight gets thrown behind it. I think the last two points can also be addressed by better caching, etc. Further into the panel, it seems like there is interest in having some kind of standardized hooks into the compiler, and Guido hems and haws a bit about that becoming implementation specific a feature, but really maybe it should become a defined part of the language. In one sense, I think if Python 3k had better function syntax/flexibility that might help a lot... then you could almost create DSLs. I mean function definition and application more like Haskell, or even something like CoffeeScript. I applaud that they standardized the print keyword to a function in Python 3K, but now I can't help but feel they should have changed all functions to be more like 'print' instead.
  - stcredzero 15y ago
    In one sense, I think if Python 3k had better function syntax/flexibility that might help a lot... then you could almost create DSLs. Reading this, I'm a bit flummoxed. I'm like, "Wow, does the mainstream science/technical computing world still not get it at all?" Probably not, and on second look ,it shouldn't be surprising. Java also suffered from the lack of first-rate DSL implementation for many years. The mainstream expectation is still often that one adapts to the language, instead of adapting the language/libraries to the problem domain. Any language that expects to be used by sci/tech needs at least to be able to implement algebras without resorting to anything but ordinary library programming in the native language, and the expectations of sci/tech programmers should match.
- kbd 15y ago
  > PyPy still have a long startup time. This is false last time I looked. Try it. It's a little more than CPython but definitely not "long". It's nothing like the JVM startup time, for instance.
ylem 15y ago
I'm not sure that (3) is likely. Python offers a number of features: 1: It's easy to learn--this cannot be understated 2: With numpy and matplotlib, you can really hit the ground running 3: There is enough language support to extend applications to GUIS, webapps, etc. 4: There's a HUGE code base that's already moved over from straight fortran, C++, IDL, etc. 5: Binding old libraries (in fortran 77, C, etc.) is fairly straightforward. No one really wants to rewrite the BLAS libraries from scratch in javascript... 6: Moving forward, PyCuda allows GPU based computing 7: Just curious, what other languages would you suggest that can satisfy some of the above? Personally, I'm meeting more and more scientific programmers who use python and a combination of C/fortran for lower level work--having a common tongue is useful!
- infinite8s 15y ago
  The core of numpy is written in C, with some unfortunate dependencies on the C Python API. It should be possible to extract the C core of numpy (with some additional work) and wrap it in Javascript or Lua.

by craigyk 15y ago

lloeki 15y ago

> put a lot more 'carrots' in there Carrots are definitely coming in Python 3.3 and up, whereas 2.6/2.7 and 3.0, 3.1, 3.2 were intended to have some overlap to ease porting.

driax 15y ago

Concerning your 1st point. While it certainly whould be nice to forget CPython and focus on PyPy, I don't think that really is an optional for the forseeable future. CPython is written in very cross-platform portable C, and supports a lot of different systems, among others IBM Mainframes. It would take a long time before PyPy gets that kind of support. PyPy is also a very different kind of implementation. I haven't heard much about any projects that have embedded it inside of an bigger application with great success. A common use of CPython. PyPy still have a long startup time. And it takes a while for the code to by optimized. The last point is something that will not change. Python is used for a lot of small scripts, and even bigger projects such as Mercurial, where PyPy will have a tough chance, if any.

craigyk 15y ago
True, good points, but not insurmountable roadblocks, especially if more weight gets thrown behind it. I think the last two points can also be addressed by better caching, etc. Further into the panel, it seems like there is interest in having some kind of standardized hooks into the compiler, and Guido hems and haws a bit about that becoming implementation specific a feature, but really maybe it should become a defined part of the language. In one sense, I think if Python 3k had better function syntax/flexibility that might help a lot... then you could almost create DSLs. I mean function definition and application more like Haskell, or even something like CoffeeScript. I applaud that they standardized the print keyword to a function in Python 3K, but now I can't help but feel they should have changed all functions to be more like 'print' instead.
- stcredzero 15y ago
  In one sense, I think if Python 3k had better function syntax/flexibility that might help a lot... then you could almost create DSLs. Reading this, I'm a bit flummoxed. I'm like, "Wow, does the mainstream science/technical computing world still not get it at all?" Probably not, and on second look ,it shouldn't be surprising. Java also suffered from the lack of first-rate DSL implementation for many years. The mainstream expectation is still often that one adapts to the language, instead of adapting the language/libraries to the problem domain. Any language that expects to be used by sci/tech needs at least to be able to implement algebras without resorting to anything but ordinary library programming in the native language, and the expectations of sci/tech programmers should match.
kbd 15y ago
> PyPy still have a long startup time. This is false last time I looked. Try it. It's a little more than CPython but definitely not "long". It's nothing like the JVM startup time, for instance.

ylem 15y ago

I'm not sure that (3) is likely. Python offers a number of features: 1: It's easy to learn--this cannot be understated 2: With numpy and matplotlib, you can really hit the ground running 3: There is enough language support to extend applications to GUIS, webapps, etc. 4: There's a HUGE code base that's already moved over from straight fortran, C++, IDL, etc. 5: Binding old libraries (in fortran 77, C, etc.) is fairly straightforward. No one really wants to rewrite the BLAS libraries from scratch in javascript... 6: Moving forward, PyCuda allows GPU based computing 7: Just curious, what other languages would you suggest that can satisfy some of the above? Personally, I'm meeting more and more scientific programmers who use python and a combination of C/fortran for lower level work--having a common tongue is useful!

infinite8s 15y ago
The core of numpy is written in C, with some unfortunate dependencies on the C Python API. It should be possible to extract the C core of numpy (with some additional work) and wrap it in Javascript or Lua.