PyContracts is a Python package that allows to declare constraints on function parameters and return values. Contracts can be specified using Python3 annotations, or inside a docstring. PyContracts supports a basic type system, variables binding, arithmetic constraints, and has several specialized contracts and an extension API.
I found that support for string contracts in Python 2.x is lacking because the string/str keyword matches only str type. For applications using Unicode strings, that's not really viable.
So I made some improvements in this regard:
I added unicode keyword that explicitly matches unicode strings (only in 2.x)
I made str keyword to match str type only (so ANSI strings in 2.x and all/Unicode strings in 3.x)
I changed string to match both str and unicode in 2.x and just str in 3.x
I'm aware that the last change modifies the original meaning of string keyword for Python 2.x so that it's more lenient. Existing contract specs using string will still allow what they used to allow, of course, but they will now also accept unicode strings in addition to str ones. So it doesn't break existing usage while (I think) making the keyword more intuitive for Python 2.x developers.
Also, the current meaning of string is not really documented anywhere (I had to find it in source, personally) and thus I suppose changing it slightly will not harm any existing usage.
I found that support for string contracts in Python 2.x is lacking because the
string
/str
keyword matches onlystr
type. For applications using Unicode strings, that's not really viable.So I made some improvements in this regard:
unicode
keyword that explicitly matchesunicode
strings (only in 2.x)str
keyword to matchstr
type only (so ANSI strings in 2.x and all/Unicode strings in 3.x)string
to match bothstr
andunicode
in 2.x and juststr
in 3.xI'm aware that the last change modifies the original meaning of
string
keyword for Python 2.x so that it's more lenient. Existing contract specs usingstring
will still allow what they used to allow, of course, but they will now also acceptunicode
strings in addition tostr
ones. So it doesn't break existing usage while (I think) making the keyword more intuitive for Python 2.x developers.Also, the current meaning of
string
is not really documented anywhere (I had to find it in source, personally) and thus I suppose changing it slightly will not harm any existing usage.