Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > any chance for contracts and invariants in Python?

Reply
Thread Tools

any chance for contracts and invariants in Python?

 
 
mrkafk@gmail.com
Guest
Posts: n/a
 
      02-14-2013

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?

 
Reply With Quote
 
 
 
 
Philipp Hagemeister
Guest
Posts: n/a
 
      02-14-2013
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, http://www.velocityreviews.com/forums/(E-Mail Removed) 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)

iEYEAREKAAYFAlEdGMkACgkQ9eq1gvr7CFx5mACeO6Iq62btJQ 4NutI/BeoX/PKk
n7QAn1cv51ntlabTH3Ow1bsOaQpr9jYA
=IaQp
-----END PGP SIGNATURE-----

 
Reply With Quote
 
 
 
 
Ian Kelly
Guest
Posts: n/a
 
      02-14-2013
On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <(E-Mail Removed)> 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.
 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      02-14-2013
On 2013-02-14 18:05, Ian Kelly wrote:
> On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <(E-Mail Removed)> 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.

 
Reply With Quote
 
Ethan Furman
Guest
Posts: n/a
 
      02-14-2013
On 02/14/2013 10:05 AM, Ian Kelly wrote:
> On Thu, Feb 14, 2013 at 10:03 AM, Philipp Hagemeister <(E-Mail Removed)> 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~

 
Reply With Quote
 
Mark Janssen
Guest
Posts: n/a
 
      02-15-2013
See the python extension called "Vigil": https://github.com/munificent/vigil
..

mark

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Accessing member via set's NON-const iterator that doesn't affect invariants Anand Hariharan C++ 2 08-30-2012 05:41 PM
Class invariants and implicit move constructors (C++0x) Scott Meyers C++ 51 11-20-2010 08:42 PM
FCC auction trick,Neocons and Chiquita,Radiation and Intelligence Contracts fusion Computer Information 0 08-03-2007 07:24 PM
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
Encapsulation and invariants bluekite2000@gmail.com C++ 3 07-29-2005 01:46 PM



Advertisments