sphinx_typesafe 0.3

Syntax for Python2 using sphinx style docstrings

This is the preferred way since you will be also documenting your code.

from sphinx_typesafe.typesafe import typesafe

@typesafe
def foo(param_a, param_b, param_c):
        """
        :type param_a:  types.StringType
        :type param_b:  types.IntType
        :type param_c:  types.NotImplementedType
        :rtype:         types.BooleanType
        """
        # Do Something
        return True

Syntax for Python2 using decorator arguments

This is an alternative approach, useful in circunstances where Sphinx-style documentation is not allowed or desired, for whatever reason.

from sphinx_typesafe.typesafe import typesafe

@typesafe( { 'param_a' : 'str',
             'param_b' : 'types.IntType',
             'param_c' : 'own_module.OwnType',
             'return'  : 'bool' } )
def foo(param_a, param_b, param_c):
        """ Some Docstring Info          """
        # Do Something
        return True

You can use any Python type

So if you have defined a Point class in module mod1 like below:

# File: mod1.py

class Point(object):
    def __init__(self, x = None, y = None):
        """ Initialize the Point. Can be used to give x,y directly."""
        self.x = x
        self.y = y

then you can employ this type in your code like this:

from mod1 import Point
from sphinx_typesafe.typesafe import typesafe

@typesafe
def foo(afunc):
    """
    :type afunc:     mod1.Point
    :rtype:          types.BooleanType
    """
    return True

Syntax for Python3

from sphinx_typesafe.typesafe import typesafe

@typesafe
def foo(param_a: str, param_b: int) -> bool:
        # Do Something
        return True

• The @typesafe decorator will then check all arguments dynamically whenever the foo is called for valid types.

• As a quoting remark from the PEP 3107: “All annotated parameter types can be any python expression.”, but for typechecking only types make sense, though.

The idea and parts of the implementation were inspired by the book: Pro Python (Expert’s Voice in Open Source)

Why it was called IcanHasTypeCheck ?

IcanHasTypeCheck (ICHTC), refers to the famous lolcats.

Why is now called sphinx_typesafe ?

Because typesafe tells immediatelly what it is about. Unfortunately, typesafe was already taken on PyPI, so sphinx_typesafe seemed to be a good alternative name which also relates to the documentation standard adopted.

0.3 (13-feb-2014)

• Several bugfixes and enhancements

  • better resolution of type names

  • fix support for methods

  • fix documentation

  • test suite now has 60 test cases

  • support for types.NoneType

  • more restrictive matching of documenation against parameters

  • support for ignoring type checking: types.NotImplementeType

  • exposing function get_class_type

0.2 (03-dec-2013)

• Full code rewiew and rewrite by Richard Gomes <rgomes.info@gmail.com>

  • @typesafe is now a class

  • Code reorganization and some optimization

  • Preparing code for porting to Python3

• New features

  • Added verification of return type of decorated functions

• Bugfixes

  • Type resolver now finds types involving multiple nested modules

  • Type resolver assumes module ‘__builtin__’ for simple names, such as ‘bool’

• Renamed to sphinx_typesafe

• Documentation rewriten in reStructuredText

• Added docs directory required by readthedocs.org

• First version deployed onto PyPI

0.1

Original version of IcanHasTypeCheck (ICHTC) by Klaas <khz@tzi.org>