Lambda the Ultimate

This PEP proposes an extension to "duck typing" called "monkey typing", that preserves most of the benefits of duck typing, while adding new features to enhance inter-library and inter-framework compatibility. The name comes from the saying, "Monkey see, monkey do", because monkey typing works by stating how one object type may mimic specific behaviors of another object type.

More here and here (from Guido).

Here you'll find code snipptes showing the API of the various libraries (all of them used to solve the same programming task), and comments about the behaviour of each of the libraries.

I am not sure if this item should be categorized as being pro-libraries, pro-a big standard libary, or pro-builtin language support for XML.

You decide.

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.

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

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 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 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"...

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.

...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.