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

[Aaron Meurer]

I'd like the ability to make "in" (i.e., __contains__) return
something other than a bool.

Also, the ability to make the x < y < z syntax would be useful.  It's
been suggested that the ability to override the boolean operators
(and, or, not) would be the way to do this (pep 335), though I'm not
100% convinced that's the way to go.

Aaron Meurer

On Mon, Feb 13, 2012 at 2: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.
>
> - 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 at 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).
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev