Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contracts #5

Open
senko opened this issue Jun 1, 2014 · 1 comment
Open

Contracts #5

senko opened this issue Jun 1, 2014 · 1 comment

Comments

@senko
Copy link
Member

senko commented Jun 1, 2014

Should we support contracts?

It would be straightforward to support contracts by supporting custom callables in type signatures. For example:

@params(a=int, b=lambda b: b != 0)
def div(a, b):
    return a / b

However, I find that syntax clunky (for contracts), compared to something like:

@contract
def div(a, b):
    return a / b

@div.requires
def div(a, b):
    assert isinstance(a, int)
    assert b != 0

But this being typedecorator, not a full-blown contracts library, I'm hesitant to grow it in that direction (unless there's popular demand).

@senko
Copy link
Member Author

senko commented Jun 2, 2014

Another problem with this approach: typedecorator by default raises TypeError (in any case, a single exception class), but with contracts it makes sense to return ValueError (or at least something different to TypeError) if contracts are violated.

This would mean we'd have to support raising various exceptions based on the type of type/constraint violation, which would make the code more convoluted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant