[Numpy-discussion] [IPython-dev] Discussion with Guido van Rossum and (hopefully) core python-dev on scientific Python and Python3
Mon Feb 13 20:19:16 CST 2012
It might be nice to turn the matrix class into a short class hierarchy,
something like this:
class TriangularMatrix(MatrixBase) # Maybe a few variations of upper/lower
triangular and whether the diagonal is stored
These other matrix classes could use packed storage, and could call the
specific optimized BLAS/LAPACK functions to get higher performance when it
is known the matrix is triangular or symmetric. I'm not sure whether this
affects the discussion of the matrix * and \ operators, but it's a
possibility to consider.
On Mon, Feb 13, 2012 at 4:53 PM, Aaron Meurer <firstname.lastname@example.org> wrote:
> 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 <email@example.com>
> > 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
> > - Extra operators/PEP 225. Here's a summary from the last time we
> > went over this, years ago at Scipy 2008:
> > and the current status of the document we wrote about it is here:
> > - 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 firstname.lastname@example.org.
> > 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
> > IPythonemail@example.com
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion