On Mon, Feb 13, 2012 at 9:55 PM, Fernando Perez <[email protected]> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
