Skip to main content

A type language for Python, including parsing, pretty-printing, type inference, type checking, and run-time contract enforcement.

Project description

This package provides a type language for communicating about Python programs and values. Humans communicating to other humans, humans communicating to the computer, and even the computer communicating to humans (via type inference and run-time contract checking).

This project has a “duck-typed” status: Whatever you can use it for, it is ready for :-)

Here is a more concrete list of implemented and intended features:

  • yes - Definition of a type language.
  • yes - Parsing and printing.
  • yes - Monitoring of type adherence for monomorphic types.
  • yes - “Any” type for easily saying exactly where things get really dynamic.
  • upcoming - Monitoring of type adherence for polymorphic types.
  • upcoming - Generation of constraints between types in a program.
  • upcoming - Best-effort inference of suitable types.
  • upcoming - Refinement types with hybrid type checking.

The Types

This type language is built from the following concepts:

  • Named types: int, long, float, complex, str, unicode, file, YourClassNameHere, …
  • List types: [int], [[long]], …
  • Tuple types: (int, long), (float, (int, Regex)), …
  • Dictionary types: {string: float}, { (str, str) : [complex] }, …
  • Union types int|long|float, str|file, …
  • The “any” type, ??, for when a value is too complex to describe in this language. May be an indication that a piece of code is metaprogramming or should be treated with gradual typing.
  • Function types:
    • str -> int
    • (int) -> int
    • (int, int) -> int
    • ( (int, int) ) -> int
    • ( str|file ) -> SomeClass
    • (int, *[str]) -> [(str, int)]
    • (int, *[int], **{int: str}) -> str
  • Object types: object(self_type, field1: int, field2: str, ...)
  • Polymorphic types (where ~a, ~b, ~c range over any other type)
    • ~a -> ~a
    • [~a] -> [~a]
    • ( (~a, ~b) ) -> ~a

Types as Contracts

The module typelanguage.enforce contains functions for using these types as run-time monitors.

Applied directly:

>>> check('{string: int}', {"hello" : "there"})

More interestingly, automatically protecting a function from bad input, for example, putting better error checking on Python’s unicode/str interactions.

>>> '\xa3'.encode('utf-8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa3 in position 0: ordinal not in range(128)

>>> @guard('unicode -> str')
... def safe_encode(s):
...    return s.encode('utf-8')

>>> safe_encode(u'hello')
>>> safe_encode('\xa3')
TypeError: Type check failed: ? does not have type unicode

Eventually, the notion of blame may be usefully incorporated, for pointing out which piece of code or agent in a distributed setting is responsible for the undesirable value.

Type Inference

In the spirit of Python and dynamic languages, type inference is best-effort. It works like so:

  1. By traversing the code, we can discover a bunch of constraints between types in different bits.
  2. Some of these constraints are going to be very easy to solve, so we can just propagate the results.
  3. Some of these constraints are not going to be practical to try to solve, so we can just drop them or insert some enforcement code if we like.

More to explore

There are many other projects that check contracts or types for Python in some way or another, but none makes communication their primary goal, with the possible exception of pySonar. As such, they make different design choices. Some are research projects or prototypes – this is not. This is a library meant for use.

And since dynamic languages are much of a muchness, it is worthwhile seeing what is happening elsewhere, though again very few projects emphasize the types themselves as fun, interesting and useful, only that the code has them.

I’m omitting the billion typed languages that compile to Javascript because those are just typed languages compiler to the assembly language of the web.

Finally, if you want to actually grok types, then contracts, then types and contracts together, then types and dynamic types together, then polymorphic type as contracts and dynamic types together, then type inference for such systems, try this chronological series of reading.


Project details

Release history Release notifications

This version
History Node


History Node


History Node


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Filename, size & hash SHA256 hash help File type Python version Upload date
typelanguage-0.3.tar.gz (17.5 kB) Copy SHA256 hash SHA256 Source None Jan 16, 2013

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging CloudAMQP CloudAMQP RabbitMQ AWS AWS Cloud computing Fastly Fastly CDN DigiCert DigiCert EV certificate StatusPage StatusPage Status page