[Python-Dev] Py2.6 ideas (original) (raw)

Andrew Koenig ark at acm.org
Fri Feb 16 22:22:31 CET 2007

Maybe Raymond's proposed record type should have two versions: one that's also a tuple, for compatibility, and one that's just a record.

FWIW, ML unifies tuples and records by defining a tuple to be a record whose component names are all consecutive integers starting with 1.

For example, in ML, the literal { name = "ark", state = "NJ" } represents a record with type { name: string, state: string }. The identifiers "name" and "state" are bound during compilation, ML being a statically typed language.

In ML, one extracts a component named foo by applying a function named #foo. So, for example, the value of

#state { name = "ark", state = "NJ" }

is "NJ", and trying to evaluate

#foo { name = "ark", state = "NJ" }

results in a compilation error because of type-checking failure.

Component names can be either identifiers or integers. So, for example,

{ name = "spells", 1 = "xyzzy", 2 = "plugh" }

is a record of type {1: string, 2: string, name: string }.

So here is the point. If the component names of a record are all positive integers with no gaps, the record is also a tuple. So, for example

{ 2 = "plugh", 1 = "xyzzy" }

has exactly the same meaning--including the same type--as

{ "xyzzy", "plugh" }

In both cases, the compiler normalizes the display, both of the value (i.e. it prints {"xyzzy", "plugh"} instead of { 2 = "plugh", 1 = "xyzzy" }, and it prints the type as

string * string

instead of (the equivalent)

{ 1: string, 2: string }

So in ML, tuple types aren't really anything special -- they're just abbreviations for elements of a particular subset of record types.

More information about the Python-Dev mailing list