[SciPy-Dev] Discussion with Guido van Rossum and (hopefully) core python-dev on scientific Python and Python3

Eric Firing efiring@hawaii....
Tue Feb 14 19:14:17 CST 2012


On 02/13/2012 11:55 AM, Fernando Perez 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:

Fernando,

For me, the biggest wart to remove is the one addressed by PEP 335:
http://www.python.org/dev/peps/pep-0335/.  (I can't comment on the 
specifics of that PEP.)

Having to choose between abusing the bitwise operators and using the 
verbose np.logical_or family is painful.

Apart from that, keep it simple.

Eric

>
> - 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.
>
> - etc...
>
> I'm putting the above just to *start* the discussion, but the real
> point is for the rest of the community to contribute ideas, so don't
> be shy.
>
> Final note: while I am here commiting to organizing and presenting
> this at the discussion with Guido (as well as contacting python-dev),
> I would greatly appreciate help with the task of summarizing this
> prior to the meeting as I'm pretty badly swamped in the run-in to
> pydata/pycon.  So if anyone is willing to help draft the summary as
> the date draws closer (we can put it up on a github wiki, gist,
> whatever), I will be very grateful.  I'm sure it will be better than
> what I'll otherwise do the last night at 2am :)
>
> Cheers,
>
> f
>
> ps - to the obvious question about webcasting the discussion live for
> remote participation: yes, we looked into it already; no,
> unfortunately it appears it won't be possible.  We'll try to at least
> have the audio recorded (and possibly video) for posting later on.
>
> pps- if you are close to Mountain View and are interested in attending
> this panel in person, drop me a line at fernando.perez@berkeley.edu.
> We have a few spots available *for this discussion only* on top of the
> pydata regular attendance (which is long closed, I'm afraid).  But
> we'll need to provide Google with a list of those attendees in
> advance.  Please indicate if you are a core python committer in your
> email, as we'll give priority for this overflow pool to core python
> developers (but will otherwise accommodate as many people as Google
> lets us).
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



More information about the SciPy-Dev mailing list