[Numpy-discussion] [cython-users] Discussion with Guido van Rossum and (hopefully) core python-dev on scientific Python and Python3

[David Cournapeau]

On Mon, Feb 13, 2012 at 9:55 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> [ I'm broadcasting this widely for maximum reach, but I'd appreciate
> it if replies can be kept to the *numpy* list, which is sort of the
> 'base' list for scientific/numerical work.  It will make it much
> easier to organize a coherent set of notes later on.  Apology if
> you're subscribed to all and get it 10 times. ]
>
> As part of the PyData workshop (http://pydataworkshop.eventbrite.com)
> to be held March 2 and 3 at the Mountain View Google offices, we have
> scheduled a session for an open discussion with Guido van Rossum and
> hopefully as many core python-dev members who can make it.  We wanted
> to seize the combined opportunity of the PyData workshop bringing a
> number of 'scipy people' to Google with the timeline for Python 3.3,
> the first release after the Python language moratorium, being within
> sight: http://www.python.org/dev/peps/pep-0398.
>
> While a number of scientific Python packages are already available for
> Python 3 (either in released form or in their master git branches),
> it's fair to say that there hasn't been a major transition of the
> scientific community to Python3.  Since there is no more development
> being done on the Python2 series, eventually we will all want to find
> ways to make this transition, and we think that this is an excellent
> time to engage the core python development team and consider ideas
> that would make Python3 generally a more appealing language for
> scientific work.  Guido has made it clear that he doesn't speak for
> the day-to-day development of Python anymore, so we all should be
> aware that any ideas that come out of this panel will still need to be
> discussed with python-dev itself via standard mechanisms before
> anything is implemented.  Nonetheless, the opportunity for a solid
> face-to-face dialog for brainstorming was too good to pass up.
>
> The purpose of this email is then to solicit, from all of our
> community, ideas for this discussion.  In a week or so we'll need to
> summarize the main points brought up here and make a more concrete
> agenda out of it; I will also post a summary of the meeting afterwards
> here.
>
> Anything is a valid topic, some points just to get the conversation started:
>
> - Extra operators/PEP 225.  Here's a summary from the last time we
> went over this, years ago at Scipy 2008:
> http://mail.scipy.org/pipermail/numpy-discussion/2008-October/038234.html,
> and the current status of the document we wrote about it is here:
> file:///home/fperez/www/site/_build/html/py4science/numpy-pep225/numpy-pep225.html.
>
> - Improved syntax/support for rationals or decimal literals?  While
> Python now has both decimals
> (http://docs.python.org/library/decimal.html) and rationals
> (http://docs.python.org/library/fractions.html), they're quite clunky
> to use because they require full constructor calls.  Guido has
> mentioned in previous discussions toying with ideas about support for
> different kinds of numeric literals...
>
> - Using the numpy docstring standard python-wide, and thus having
> python improve the pathetic state of the stdlib's docstrings?  This is
> an area where our community is light years ahead of the standard
> library, but we'd all benefit from Python itself improving on this
> front.  I'm toying with the idea of giving a lighting talk at PyConn
> about this, comparing the great, robust culture and tools of good
> docstrings across the Scipy ecosystem with the sad, sad state of
> docstrings in the stdlib.  It might spur some movement on that front
> from the stdlib authors, esp. if the core python-dev team realizes the
> value and benefit it can bring (at relatively low cost, given how most
> of the information does exist, it's just in the wrong places).  But
> more importantly for us, if there was truly a universal standard for
> high-quality docstrings across Python projects, building good
> documentation/help machinery would be a lot easier, as we'd know what
> to expect and search for (such as rendering them nicely in the ipython
> notebook, providing high-quality cross-project help search, etc).
>
> - Literal syntax for arrays?  Sage has been floating a discussion
> about a literal matrix syntax
> (https://groups.google.com/forum/#!topic/sage-devel/mzwepqZBHnA).  For
> something like this to go into python in any meaningful way there
> would have to be core multidimensional arrays in the language, but
> perhaps it's time to think about a piece of the numpy array itself
> into Python?  This is one of the more 'out there' ideas, but after
> all, that's the point of a discussion like this, especially
> considering we'll have both Travis and Guido in one room.
>
> - Other syntactic sugar? Sage has "a..b" <=> range(a, b+1), which I
> actually think is  both nice and useful... There's also the question
> of allowing "a:b:c" notation outside of [], which has come up a few
> times in conversation over the last few years. Others?
>
> - The packaging quagmire?  This continues to be a problem, though
> python3 does have new improvements to distutils.  I'm not really up to
> speed on the situation, to be frank.  If we want to bring this up,
> someone will have to provide a solid reference or volunteer to do it
> in person.

I will be at pydata, so I can try to get an elevator pitch ready for
the packaging situation. I may be biased, but I don't think distutils2
actually improved the situation much  for the scientific community
(most likely made it worse by having yet one more solution without
much improvement).

In particular;
 - commands are still coupled to each other
 - it is still not possible to use an actual build system with
dependency handling
 - no sensible API (distutils2 cannot be used as a library)

cheers,

David