

PyData 2012: Guido van Rossum discusses Python w/ the scientific community - mrknvi
http://marakana.com/s/2012_pydata_workshop_panel_with_guido_van_rossum,1091/index.html

======
craigyk
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?)

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

------
joshklein
There were many great data-related Python presentations and discussions over
the past few weeks at Strata, PyData 2012, and PyCon. There's a lot of
momentum in the space - we were thrilled to be sponsors & participants.
Everyone we met was smart, capable, and best of all, exceedingly friendly.

If you want to be a part of the ongoing discussion, please join the new pydata
mailing list (<http://groups.google.com/group/pydata>) and irc channel
(#pydata on irc.freenode.net).

