Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38860 > unrolled thread

any chance for contracts and invariants in Python?

Back to article view | Back to comp.lang.python

Contents

  any chance for contracts and invariants in Python? mrkafk@gmail.com - 2013-02-14 03:42 -0800
    Re: any chance for contracts and invariants in Python? Philipp Hagemeister <phihag@phihag.de> - 2013-02-14 18:03 +0100
    Re: any chance for contracts and invariants in Python? Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-14 11:05 -0700
    Re: any chance for contracts and invariants in Python? MRAB <python@mrabarnett.plus.com> - 2013-02-14 18:18 +0000
    Re: any chance for contracts and invariants in Python? Ethan Furman <ethan@stoneleaf.us> - 2013-02-14 10:33 -0800
    Re: any chance for contracts and invariants in Python? Mark Janssen <dreamingforward@gmail.com> - 2013-02-14 18:33 -0800

#38860 — any chance for contracts and invariants in Python?

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?

[toc] | [next] | [standalone]

#38870

[Multipart message — attachments visible in raw view] — view raw

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, mrkafk@gmail.com 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?
> 

[toc] | [prev] | [next] | [standalone]

#38872

On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <phihag@phihag.de> 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.

[toc] | [prev] | [next] | [standalone]

#38874

On 2013-02-14 18:05, Ian Kelly wrote:
> On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <phihag@phihag.de> 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.

[toc] | [prev] | [next] | [standalone]

#38876

On 02/14/2013 10:05 AM, Ian Kelly wrote:
> On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <phihag@phihag.de> 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~

[toc] | [prev] | [next] | [standalone]

#38902

[Multipart message — attachments visible in raw view] — view raw

See the python extension called "Vigil": https://github.com/munificent/vigil
.

mark

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web