SciPy'06: First Morning

Guido van Rossum’s Keynote

• Python 2.5 coming Real Soon (Sept 12)
• Python 3000 is a brand-new revision of the language
  • Name chosen as a dig at Windows 2000, and so that it couldn't possibly be late
• Fix design bugs dating from 1990-91 + get rid of deprecated features
• First time Guido has allowed himself to be backward incompatible
• Need process, but don't want to become C++ or the next Perl 6
• Alpha early 2007, final a year later (early 2008)
• Cares a lot about bringing users with him
  • Will go as far as 2.9 (run out of digits)
• Changes:
  • New keywords allowed
  • dict.keys(), range(), zip() won't return lists
  • All strings Unicode; mutable 'bytes' data type
  • Binary file I/O redesign
  • Drop <> as an alias for !=
  • Etc.
• See PEP 3099 for things that won't happen (e.g., programmable syntax)
• Can't do perfect mechanical translation (dynamic languages)
  • Use pychecker-like tool to handle 80% of cases
  • Create instrumented Python 2.x that warns about "doomed" constructs
• See PEP 3100 for the laundry list
• Small points
  • Kill classic classes
  • Exceptions must derive from BaseException
  • int/int will return a float
  • Remove last differences between int and long
  • Absolute import by default
  • Kill sys.exc_type and friends
  • Kill dict.has_key, file.xreadlines()
  • Kill apply(), input(), buffer(), coerce()
  • Kill ancient library modules; more stdlib cleanup
  • exec becomes a funciton again
  • Kill `x` in favor of repr(x)
  • Change except clause syntax to exception E1, E2, E3 as err
    • Means "as" becomes a keyword
  • [f(x) for x in S] becoms sugar for list(f(x) for x in S)
    • General trend in Python away from lists toward more abstract structures
  • Kill raise E, arg in favor of raise E(arg)
  • zip becomes izip
• lambda lives!
• String types reform (bytes and str instead of str and unicode)
  • All data s either ibnary or text (conversions happen at I/O time)
  • Different APIs for binary and text streams
• New standard I/O stack
  • C stdio has too many problems
  • Borrow from Java streams API (bleah)
• Print becomes a function (boo)
  • See mailing list thread for justification
  • But I think that putting the output file at the end in print(x, y, file=z) is going to trip people up
• Dict views instead of lists
  • dict.keys() and dict.items() return a set view
  • dict.views() will return a bag (multiset) view
  • Can delete from (but not add to) a view
    • Modifies the dict accordingly
• Drop default implementations of comparison operators
  • <, <=, etc., currently compare by address—will raise TypeError
  • == and != should remain (useful)
• Generic and overloaded functions (see his blog—running out of time)
• Python sprints coming up (Aug 21-24)
• Q&A
  • Py3K team is smaller than Perl6—GvR optimistic that people will get the work done
  • Taking advantage of multicore?
    • GvR not a big fan of threads
    • Prefers loose coupling (one process per core)
    • Last attempt to get rid of the GIL slowed Python down by 2X
    • But neither Jython nor IronPython have a GIL
  • Will C-Python API change much?
    • Yup—just like the language
  • PyPy/type inference?
    • Python 4.0 or a sibling language

Travis Oliphant on the State of NumPy

• Chair thanked him for everything he's done to fix numerical Python—standing ovation (well deserved)
• NumPy 1.0 rc1 will be out in a few weeks
• Walked through design—tradeoffs between flexibility, portability, and performance very well thought through
• One part I enjoyed was the way he flipped back and forth between PowerPoint and the interpreter
  • Clear that for him, Python is a tool for thinking with
• Showed off weave, an Enthought tool for embedding C in Python for array programming
• Also shows off Pyrex (another tool for the same purpose)

Fernando Perez: Python for Modern Scientific Algorithm Development

• "Why is Python more than 'free MATLAB'?"
  • Power of built-in datatypes, higher-level programming, etc.

Michael Aivazis: “Building a Distributed Component Framework”

• Described a medium-sized framework called pyre
  • 1200 classes, 75K lines of Python, 30K lines of C++
  • Has been running in various incarnations for almost ten years
• Good discussion of architectural issues—perfect example of the kind of researcher I'd like Software Carpentry to produce