Python

Ian Bicking: The challenge of metaprogramming

So I think it's really important that we approach metaprogramming with caution. I think Guido has been right to resist macros. Not because they are necessarily wrong, but because we haven't yet figured out how to do them right. And maybe we never will, maybe source code simply isn't the right level for abstractions. I think it's good that Python doesn't do tail-call elimination; it seems like a nice feature, but in subtle ways it makes the language harder. And I think continuations could lead to bad things. There are wrong paths on the road to higher-level programming. (Though in some ways I also feel the opposite: tell us not to shoot ourselves in the foot, and expect us to listen, don't assume we'll abuse every feature that exists; there's always a tension in these design choices.)

This deserves more attention than I can give it right now, but I am sure others here will want to comment.

Guido: Adding Optional Static Typing to Python -- Part II

Part II (see Part I discussion on LtU).

Among the notions discussed: Interfaces and Design By Contract, Parameterized Types and Types vs. Classes.

Python is... slow?

An interesting blog post and comment thread.

Adding Optional Static Typing to Python

Link: Guido van Rossum broaches the subject of type tagging for Python.

Optional static typing has long been requested as a Python feature. It's been studied in depth before (e.g. on the type-sig) but has proven too hard for even a PEP to appear. In this post I'm putting together my latest thoughts on some issues, without necessarily hoping to solve all problems.

Static vs. dynamic is a never-ending thread in most PL discussions these days. But designing a type system is a *hard* task, one which I'm not sure doesn't require from a ground on up approach. But it would be nice if you could choose to work your way into, though most of the Smalltalk crowd will inform us that Strongtalk never did quite catch on.


(accompanying discussion forum)

PyPy wins a funding contract with the EU

PyPy aims at producing a simple runtime-system for the Python language,

Our primary Scientific objective is to investigate novel techniques (based on Aspect-Oriented-Programming code generation and abstract interpretation) for the implementation of practical dynamic languages, breaking the compromise between flexibility, simplicity and performance trade-offs and expanding the range (small-to-large) of directly supportable runtime platforms.

Logix: Multi-Language Programming

Also advertized as Lisp-in-Python, Logix seems like an interesting project.

Logix provides syntax extension mechanisms (i.e., macros) that support language extension and encourage the use of embedded DSLs.

Languages can be encapsulated as objects, users can switch between them dynamically, etc.

Some call this sort of thing "language oriented programming"...

Cool Python "spreadsheet"

Use eval() to drive spreadsheet style logic. The sleeper feature of Py2.4 is the ability to use any object with a mapping interface as the locals argument to eval().

Cute Python language hack.

Languages that allow you to hook into their variable lookup logic open the door to many cool hacks.

SciPy 2004 Papers

...are online. The PyTables (PDF) work is intriguing. It offers high-speed, high-volume access to HDF. Somewhere along the way came a comparison of HDF to PDB from the (old?) PACT project at LLNL.

Python, metaprogramming, and macros

A nice blogpost from Ian Bicking.

Release of Python 2.4, release candidate 1

What's New in Python 2.4 details the changes and additions in this release. Download the release here.

Most of the additions were discussed here in the past. Notable among them are generator expressions and function and method decorators.

XML feed