any chance for contracts and invariants in Python?

Discussion in 'Python' started by mrkafk@gmail.com, Feb 14, 2013.

  1. Guest

    This PEP seems to be gathering dust:

    http://www.python.org/dev/peps/pep-0316/

    I was thinking the other day, would contracts and invariants not be better than unit tests? That is, they could do what unit tests do and more, bc they run at execution time and not just at development time?
    , Feb 14, 2013
    #1
    1. Advertising

  2. I don't know anything about the status of this PEP or why it hasn't been
    implemented, but here's what strikes me as obviously complex:

    Doesn't one need to traverse the entire class hierarchy on every
    function call? So if I have

    class A:
    def foo(self):
    return 1

    class B(A):
    "inv: True"
    def foo(self):
    "post: __return__ == 2"
    return 2

    Now, I have
    f = B().foo
    f()
    . What does Python do?

    If your answer is
    1. Look up class of f
    2. Check its invariant (succeeds)
    3. Execute the function
    4. Check post conditions of f (succeeds)
    5. return 2

    Then what will I get if I run any of the following programs:

    A.foo.__doc__ = 'inv: __return__ == 1'
    f()

    def _foo(self):
    'post: __return__ == 3'
    A.foo = _foo
    f()

    A.__doc__ = 'inv: False'
    f()

    So any implementation has to choose one of the following:

    1. Ignore invariants and postconditions of inherited classes - defeats
    the purpose.
    2. Only respect definitions in classes and methods in the original
    definition, which would be unpythonic
    3. Only respect the "original" definitions, for some value of original.
    Simarily, this would break monkey patching.
    4. Update all subclasses whenever something changes.
    5. Traverse the entire class hierarchy for every method call.

    Which option should be picked?

    Additionally, the reference implementation is not actually a fork of
    cpython (or a metaclass), but a Python script that - as far as I
    understand - I have to call manually to start using contracts.

    - Philipp


    On 14.02.2013 12:42, wrote:
    >
    > This PEP seems to be gathering dust:
    >
    > http://www.python.org/dev/peps/pep-0316/
    >
    > I was thinking the other day, would contracts and invariants not be better than unit tests? That is, they could do what unit tests do and more, bc they run at execution time and not just at development time?
    >




    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.12 (GNU/Linux)

    iEYEAREKAAYFAlEdGMkACgkQ9eq1gvr7CFx5mACeO6Iq62btJQ4NutI/BeoX/PKk
    n7QAn1cv51ntlabTH3Ow1bsOaQpr9jYA
    =IaQp
    -----END PGP SIGNATURE-----
    Philipp Hagemeister, Feb 14, 2013
    #2
    1. Advertising

  3. Ian Kelly Guest

    On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <> wrote:
    > So any implementation has to choose one of the following:
    >
    > 1. Ignore invariants and postconditions of inherited classes - defeats
    > the purpose.
    > 2. Only respect definitions in classes and methods in the original
    > definition, which would be unpythonic
    > 3. Only respect the "original" definitions, for some value of original.
    > Simarily, this would break monkey patching.
    > 4. Update all subclasses whenever something changes.
    > 5. Traverse the entire class hierarchy for every method call.
    >
    > Which option should be picked?


    #5, with the expectation that like assertions the entire machinery
    would be turned off when the -O flag is passed, or perhaps even
    requiring a special flag to enable in the first place. Contracts and
    invariants would only be used in development work, not in production
    code.
    Ian Kelly, Feb 14, 2013
    #3
  4. MRAB Guest

    On 2013-02-14 18:05, Ian Kelly wrote:
    > On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <> wrote:
    >> So any implementation has to choose one of the following:
    >>
    >> 1. Ignore invariants and postconditions of inherited classes - defeats
    >> the purpose.
    >> 2. Only respect definitions in classes and methods in the original
    >> definition, which would be unpythonic
    >> 3. Only respect the "original" definitions, for some value of original.
    >> Simarily, this would break monkey patching.
    >> 4. Update all subclasses whenever something changes.
    >> 5. Traverse the entire class hierarchy for every method call.
    >>
    >> Which option should be picked?

    >
    > #5, with the expectation that like assertions the entire machinery
    > would be turned off when the -O flag is passed, or perhaps even
    > requiring a special flag to enable in the first place. Contracts and
    > invariants would only be used in development work, not in production
    > code.
    >

    Maybe what it needs is a decorator that parses the docstrings, creates
    functions to do the checks, and then wraps them around the functions.
    MRAB, Feb 14, 2013
    #4
  5. Ethan Furman Guest

    On 02/14/2013 10:05 AM, Ian Kelly wrote:
    > On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <> wrote:
    >> So any implementation has to choose one of the following:
    >>
    >> 1. Ignore invariants and postconditions of inherited classes - defeats
    >> the purpose.
    >> 2. Only respect definitions in classes and methods in the original
    >> definition, which would be unpythonic
    >> 3. Only respect the "original" definitions, for some value of original.
    >> Simarily, this would break monkey patching.
    >> 4. Update all subclasses whenever something changes.
    >> 5. Traverse the entire class hierarchy for every method call.
    >>
    >> Which option should be picked?

    >
    > #5, with the expectation that like assertions the entire machinery
    > would be turned off when the -O flag is passed, or perhaps even
    > requiring a special flag to enable in the first place. Contracts and
    > invariants would only be used in development work, not in production
    > code.


    I was under the impression that the real power of contracts was when
    they are /not/ turned off -- the errors we don't catch in development
    are the serious ones. ;)

    --
    ~Ethan~
    Ethan Furman, Feb 14, 2013
    #5
  6. Mark Janssen Guest

    Mark Janssen, Feb 15, 2013
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    352
    Puppet_Sock
    Jul 29, 2005
  2. Paulo J. Matos

    Contracts for Python

    Paulo J. Matos, Oct 28, 2008, in forum: Python
    Replies:
    1
    Views:
    395
    alex23
    Oct 29, 2008
  3. Scott Meyers
    Replies:
    51
    Views:
    4,314
    Chris Cochran
    Nov 20, 2010
  4. Rodney Gomes

    new python contracts library

    Rodney Gomes, Jul 12, 2011, in forum: Python
    Replies:
    0
    Views:
    192
    Rodney Gomes
    Jul 12, 2011
  5. Anand Hariharan
    Replies:
    2
    Views:
    387
    Anand Hariharan
    Aug 30, 2012
Loading...

Share This Page