Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'subject:Python': 0.05; 'cpython': 0.05; 'definitions': 0.07; 'purpose.': 0.07; 'python': 0.09; 'definition,': 0.09; 'fork': 0.09; 'inherited': 0.09; 'pep': 0.09; 'subclasses': 0.09; 'url:peps': 0.09; 'cc:addr:python-list': 0.10; 'def': 0.10; 'ignore': 0.13; "hasn't": 0.15; 'call?': 0.16; 'filename:fname piece:signature': 0.16; 'hierarchy': 0.16; 'implemented,': 0.16; 'traverse': 0.16; 'wrote:': 0.17; 'url:dev': 0.17; 'obviously': 0.18; 'tests': 0.18; '(or': 0.18; 'cc:2**0': 0.23; 'seems': 0.23; 'cc:no real name:2**0': 0.24; 'script': 0.24; 'cc:addr:python.org': 0.25; 'header:In-Reply-To:1': 0.25; 'header :User-Agent:1': 0.26; 'execution': 0.27; "doesn't": 0.28; 'run': 0.28; 'post': 0.28; 'class': 0.29; 'classes': 0.30; 'call.': 0.30; 'function': 0.30; 'url:python': 0.32; 'more,': 0.32; 'could': 0.32; 'received:192.168.2': 0.34; 'subject:?': 0.35; 'something': 0.35; 'but': 0.36; 'url:org': 0.36; 'method': 0.36; 'anything': 0.36; 'should': 0.36; 'execute': 0.37; 'does': 0.37; 'option': 0.37; 'why': 0.37; 'far': 0.37; 'subject:: ': 0.38; 'unit': 0.38; 'some': 0.38; 'received:192': 0.39; 'received:192.168': 0.40; 'your': 0.60; 'day,': 0.60; 'respect': 0.63; 'email addr:gmail.com': 0.63; 'choose': 0.65; 'gathering': 0.71; 'original.': 0.84; 'programs:': 0.84; 'subject:any': 0.84; 'contracts': 0.91 Date: Thu, 14 Feb 2013 18:03:04 +0100 From: Philipp Hagemeister User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: mrkafk@gmail.com Subject: Re: any chance for contracts and invariants in Python? References: <70c4a8a5-0e8d-4e5c-b0cd-e4ccd90c5cb3@googlegroups.com> In-Reply-To: <70c4a8a5-0e8d-4e5c-b0cd-e4ccd90c5cb3@googlegroups.com> X-Enigmail-Version: 1.4 OpenPGP: id=FAFB085C Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAD7C98ABF4BC09B5583DCCBF" Cc: python-list@python.org X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 93 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1360863198 news.xs4all.nl 6916 [2001:888:2000:d::a6]:57457 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:38870 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD7C98ABF4BC09B5583DCCBF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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__ =3D=3D 2" return 2 Now, I have f =3D B().foo f() =2E 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__ =3D 'inv: __return__ =3D=3D 1' f() def _foo(self): 'post: __return__ =3D=3D 3' A.foo =3D _foo f() A.__doc__ =3D '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: >=20 > This PEP seems to be gathering dust: >=20 > http://www.python.org/dev/peps/pep-0316/ >=20 > I was thinking the other day, would contracts and invariants not be bet= ter 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? >=20 --------------enigAD7C98ABF4BC09B5583DCCBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREKAAYFAlEdGMkACgkQ9eq1gvr7CFx5mACeO6Iq62btJQ4NutI/BeoX/PKk n7QAn1cv51ntlabTH3Ow1bsOaQpr9jYA =IaQp -----END PGP SIGNATURE----- --------------enigAD7C98ABF4BC09B5583DCCBF--