Re: [Python-ideas] Pre-conditions and post-conditions

Hi, I implemented a sphinx extension to include contracts in the documentation: https://github.com/Parquery/sphinx-icontract The extension supports inheritance. It lists all the postconditions and invariants including the inherited one. The preconditions are grouped by classes with ":requires:"

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, Again a brief update. * icontract supports now static and class methods (thanks to my colleague Adam Radomski) which came very handy when defining a group of functions as an interface *via* an abstract (stateless) class. The implementors then need to all satisfy the contracts without needing

Re: [Python-ideas] Pre-conditions and post-conditions

Hi David Maertz and Michael Lee, Thank you for raising the points. Please let me respond to your comments in separation. Please let me know if I missed or misunderstood anything. *Assertions versus contracts.* David wrote: > I'm afraid that in reading the examples provided it is difficulties

Re: [Python-ideas] Pre-conditions and post-conditions

I just want to point out that you don't need permission from anybody to start a library. I think developing and popularizing a contracts library is a reasonable goal -- but that's something you can start doing at any time without waiting for consensus. And if it gets popular enough, maybe it'll

Re: [Python-ideas] Pre-conditions and post-conditions

I'm afraid that in reading the examples provided it is difficulties for me not simply to think that EVERY SINGLE ONE of them would be FAR easier to read if it were an `assert` instead. The API of the library is a bit noisy, but I think the obstacle it's more in the higher level design for me.

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, Let me make a couple of practical examples from the work-in-progress ( https://github.com/Parquery/pypackagery, branch mristin/initial-version) to illustrate again the usefulness of the contracts and why they are, in my opinion, superior to assertions and unit tests. What follows is a list of

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, A brief follow-up (latest version 1.5.3): I removed the dependency on meta package so that now all comprehensions and generator expressions work. I still had to depend on asttokens in order to get the source code of the condition function. Is there maybe an alternative solution which uses only

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, I implemented the inheritance via meta classes and function and class attributes for pre/postconditions and invariants, respectively. Unless I missed something, this is as far as we can go without the proper language support with a library based on decorators:

Re: [Python-ideas] Pre-conditions and post-conditions

Michel Desmoulin wrote: > Isn't the purpose of "assert" to be able to do design by contract ? > > assert test, "error message is the test fail" > > I mean, you just write your test, dev get a feedback on problems, and > prod can remove all assert using -o. > > What more do you need ? Good

Re: [Python-ideas] Pre-conditions and post-conditions

Isn't the purpose of "assert" to be able to do design by contract ? assert test, "error message is the test fail" I mean, you just write your test, dev get a feedback on problems, and prod can remove all assert using -o. What more do you need ? Le 15/08/2018 à 23:06, Marko Ristin-Kaufmann

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, Sep 04, 2018 at 10:50:27AM +1200, Greg Ewing wrote: > Jonathan Fine wrote: > >I've just read and article which makes a good case for providing > >pre-conditions and post-conditions. > > > >http://pgbovine.net/python-unreadable.htm > > There's nothing in there that talks about PBC-style

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, Sep 04, 2018 at 12:08:31AM +0100, Ivan Levkivskyi wrote: > On Mon, 3 Sep 2018 at 23:51, Greg Ewing wrote: > > > Jonathan Fine wrote: > > > I've just read and article which makes a good case for providing > > > pre-conditions and post-conditions. > > > > > >

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, 3 Sep 2018 at 23:51, Greg Ewing wrote: > Jonathan Fine wrote: > > I've just read and article which makes a good case for providing > > pre-conditions and post-conditions. > > > > http://pgbovine.net/python-unreadable.htm > > There's nothing in there that talks about PBC-style executable

Re: [Python-ideas] Pre-conditions and post-conditions

Jonathan Fine wrote: I've just read and article which makes a good case for providing pre-conditions and post-conditions. http://pgbovine.net/python-unreadable.htm There's nothing in there that talks about PBC-style executable preconditions and postconditions, it's all about documenting the

Re: [Python-ideas] Pre-conditions and post-conditions

I've just read and article which makes a good case for providing pre-conditions and post-conditions. http://pgbovine.net/python-unreadable.htm The main point is: "without proper comments and documentation, even the cleanest Python code is incomprehensible 'in-the-large'." I find the article to

Re: [Python-ideas] Pre-conditions and post-conditions

Hi Ethan, You are right, I deleted it without noticing. It should say: pre(len(lst) < 10). Le jeu. 30 août 2018 à 23:02, Ethan Furman a écrit : > On 08/30/2018 01:49 PM, Marko Ristin-Kaufmann wrote: > > > classC(A): > > # C.some_func also inherits the contracts from A. > > # It

Re: [Python-ideas] Pre-conditions and post-conditions

def example_func(x, y): def __assert_before__(example_func): #implicit, AST-able assertion expressions # ... code def __assert_after__(example_func): # def __assert_after__invariants_02(example_func): # " But these need to be composed / mixed in in MRO

Re: [Python-ideas] Pre-conditions and post-conditions

On 08/30/2018 01:49 PM, Marko Ristin-Kaufmann wrote: classC(A): # C.some_func also inherits the contracts from A. # It weakens the precondition: # it operates either on sorted lists OR # the lists that are shorter than 10 elements. # # It

Re: [Python-ideas] Pre-conditions and post-conditions

On Thu, Aug 30, 2018 at 3:44 AM Marko Ristin-Kaufmann < marko.ris...@gmail.com> wrote: > Related to the text I emphasized, would you mind to explain a bit more > in-depth which features you have in mind? I see contracts formally written > out and automatically verified as a completely

Re: [Python-ideas] Pre-conditions and post-conditions

On Wed, 29 Aug 2018 at 23:08, Marko Ristin-Kaufmann wrote: > > Hi, > I think we got entangled in a discussion about whether design-by-contract is > useful or not. IMO, the personal experience ("I never used/needed this > feature") is quite an inappropriate rule whether something needs to be >

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, @David Mertz, Eric Fahlgren re inheritance: thank you very much for your suggestions. I will try to see how inheritance can be implemented with metaclasses and annotations and put it into icontract library. @David Mertz re costs: > Adding a new feature, even if it is *technically* backwards

Re: [Python-ideas] Pre-conditions and post-conditions

On 08/29/2018 04:53 PM, Hugh Fisher wrote: From: Marko Ristin-Kaufmann: There seems to be evidence that design-by-contract is useful. Let me cite Bertrand Meyer from his article "Why not program right?" that I already mentioned before: I don't think that being useful by itself should be

Re: [Python-ideas] Pre-conditions and post-conditions

> Date: Thu, 30 Aug 2018 00:07:04 +0200 > From: Marko Ristin-Kaufmann ... > I think we got entangled in a discussion about whether design-by-contract > is useful or not. IMO, the personal experience ("I never used/needed this > feature") is quite an inappropriate rule whether something needs to

Re: [Python-ideas] Pre-conditions and post-conditions

On 8/29/2018 6:39 PM, Eric Fahlgren wrote: On Wed, Aug 29, 2018 at 3:07 PM Marko Ristin-Kaufmann mailto:marko.ris...@gmail.com>> wrote: Could you please elaborate a bit? I don't see how the annotations would make the contracts invoked on inheritance. Consider this simple case:

Re: [Python-ideas] Pre-conditions and post-conditions

replying to the list now... On Thu, 30 Aug 2018 at 00:11, Ivan Levkivskyi wrote: > On Wed, 29 Aug 2018 at 13:18, Steven D'Aprano wrote: > >> I didn't want to embarass Ivan any further by seemingly picking on his >> opinion about contracts being always statically checked, but when I >> asked

Re: [Python-ideas] Pre-conditions and post-conditions

The technique Eric suggests is probably better than what I had in mind. But I was thinking you could have an "inherit" decorator for methods (or for a class as a whole). It's easy enough for a decorator to attach a `.__contracts__` attribute to either the class or the individual methods. Then the

Re: [Python-ideas] Pre-conditions and post-conditions

Jonathan Fine wrote: My message of support for Ivan quoted the Eiffel docs. https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with

Re: [Python-ideas] Pre-conditions and post-conditions

On Wed, Aug 29, 2018 at 02:26:54PM +0100, Jonathan Fine wrote: > This is about a difference of opinion regarding design by contract and > static checking, that Steve D'Aprano has re-raised. Steve wrote that > Ivan Levkivskyi's opinion was that: > > > contracts [are] always statically checked >

Re: [Python-ideas] Pre-conditions and post-conditions

This is about a difference of opinion regarding design by contract and static checking, that Steve D'Aprano has re-raised. Steve wrote that Ivan Levkivskyi's opinion was that: > contracts [are] always statically checked This is what Ivan wrote: > TBH, I think one of the main points of design by

Re: [Python-ideas] Pre-conditions and post-conditions

I didn't want to embarass Ivan any further by seemingly picking on his opinion about contracts being always statically checked, but when I asked off-list I got told to reword and post it here. So here it is. Sorry Ivan if this makes you feel I'm picking on you, that isn't my intention. On

Re: [Python-ideas] Pre-conditions and post-conditions

On Wed, Aug 29, 2018 at 09:23:02AM +0200, Jacco van Dorp wrote: > Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano : > > > On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote: > > > Hi, > > > To clarify the benefits of the contracts, let me give you an example from > > > our

Re: [Python-ideas] Pre-conditions and post-conditions

On Wed, Aug 29, 2018 at 05:52:46PM +1200, Greg Ewing wrote: > Wes Turner wrote: > >I'm going to re-write that in a pseudo-Eiffel like syntax: > > Maybe some magic could be done to make this work: > > def __init__(self, img: np.ndarray, x: int, y: int, width: int, > height:

Re: [Python-ideas] Pre-conditions and post-conditions

Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano : > On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote: > > Hi, > > To clarify the benefits of the contracts, let me give you an example from > > our code base: > > > > @icontract.pre(lambda x: x >= 0) > >

Re: [Python-ideas] Pre-conditions and post-conditions

I've never used contracts, so excuse me if I didn't get how they would work, and what they should do. The last example is about pre-post conditions in a class constructor. But I imagine this is not the only case where one would want to define contracts, like probably: within methods that

Re: [Python-ideas] Pre-conditions and post-conditions

I Op wo 29 aug. 2018 07:53 schreef Greg Ewing : > Wes Turner wrote: > > I'm going to re-write that in a pseudo-Eiffel like syntax: > > Maybe some magic could be done to make this work: > > def __init__(self, img: np.ndarray, x: int, y: int, width: int, > height: int) ->

Re: [Python-ideas] Pre-conditions and post-conditions

Wes Turner wrote: I'm going to re-write that in a pseudo-Eiffel like syntax: Maybe some magic could be done to make this work: def __init__(self, img: np.ndarray, x: int, y: int, width: int, height: int) -> None: def __require__(): x >= 0

Re: [Python-ideas] Pre-conditions and post-conditions

How are conditions relaxed/overridden in Eiffel without a named reference? That looks much more readable. Expressions within such blocks are implicitly assertTrue(s). What sort of test generation from said nameless expressions would be most helpful? On Tuesday, August 28, 2018, Steven D'Aprano

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote: > Hi, > To clarify the benefits of the contracts, let me give you an example from > our code base: > > @icontract.pre(lambda x: x >= 0) > @icontract.pre(lambda y: y >= 0) > @icontract.pre(lambda width: width >= 0) >

Re: [Python-ideas] Pre-conditions and post-conditions

I admit that I don't care that much about pre- and post-conditions. Like a lot of people I've written a you library to handle some cases, but was never motivates to make it better or use ones folks have refined. I definitely oppose dedicated syntax. Nonetheless, I'll say that it's really not hard

Re: [Python-ideas] Pre-conditions and post-conditions

I now fully understand your use case. IIUC, what would make this easier is a syntax for defining preconditions, post conditions, and invariants that supports: * inheritance, composition (mixins) This isn't possible with decorators because there's no reference to the post-decorated

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, To clarify the benefits of the contracts, let me give you an example from our code base: @icontract.pre(lambda x: x >= 0) @icontract.pre(lambda y: y >= 0) @icontract.pre(lambda width: width >= 0) @icontract.pre(lambda height: height >= 0) @icontract.pre(lambda x, width, img: x + width <=

Re: [Python-ideas] Pre-conditions and post-conditions

Thanks for the explanation. This may be a bit OT, but is there a good way to do runtime assertions (in particular for data validation) that's as easy as assert? - self.assertEqual (unittest.TestCase.assertEqual) is hardly usable in other class instances, - pytest can be used at runtime but has

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, Aug 27, 2018 at 11:01:21AM -0400, Wes Turner wrote: > Runtime checks: data validation & code validation > Compile-time checks: code validation > > What sort of data validation is appropriate for assert statements or > contacts that may be skipped due to trading performance for more risk >

[Python-ideas] Pre-conditions and post-conditions

Runtime checks: data validation & code validation Compile-time checks: code validation What sort of data validation is appropriate for assert statements or contacts that may be skipped due to trading performance for more risk ('optimized out')? Checking the value of a Number? Checking that a

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, Aug 27, 2018 at 11:00:22PM +1000, Chris Angelico wrote: > Sometimes "type" doesn't mean the same thing to the language and to > the human. Suppose you're trying to create a Python script that > replicates a C program; you might want to declare that a variable is > not of type "integer"

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, Aug 27, 2018 at 10:50 PM, Steven D'Aprano wrote: > On Mon, Aug 27, 2018 at 12:12:22PM +0100, Ivan Levkivskyi wrote: >> Contract in 99% of cases is just another word for type (maybe a very >> complex type like `DAG[T] <: Graph[T]`). >> Everything else, like `x >= y` is better expressed as

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, Aug 27, 2018 at 12:12:22PM +0100, Ivan Levkivskyi wrote: > On Mon, 27 Aug 2018 at 11:39, Steven D'Aprano wrote: > > > On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote: > > > TBH, I think one of the main points of design by contract is that > > contracts > > > are verified

Re: [Python-ideas] Pre-conditions and post-conditions

Ivan and Steve wrote >> TBH, I think one of the main points of design by contract is that contracts >> are verified statically. > No, that's not correct. > https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions The page from Steve supplied (URL above)

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, 27 Aug 2018 at 11:39, Steven D'Aprano wrote: > On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote: > > TBH, I think one of the main points of design by contract is that > contracts > > are verified statically. > > No, that's not correct. Contracts may be verified statically

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, Aug 27, 2018 at 09:24:20AM +0100, Ivan Levkivskyi wrote: > TBH, I think one of the main points of design by contract is that contracts > are verified statically. No, that's not correct. Contracts may be verified statically if the compiler is able to do so, but they are considered runtime

Re: [Python-ideas] Pre-conditions and post-conditions

On Mon, Aug 27, 2018 at 09:04:21AM +0200, Jacco van Dorp wrote: > Total noob speaking here, but > > Those contracts are mostly important during development right ? That assumes that production code is free of bugs. Usual practice in the Eiffel world is, I believe, to disable post-

Re: [Python-ideas] Pre-conditions and post-conditions

TBH, I think one of the main points of design by contract is that contracts are verified statically. For runtime contract checking I would rather recommend hypothesis library (or similar). -- Ivan On Mon, 27 Aug 2018 at 08:05, Jacco van Dorp wrote: > Total noob speaking here, but > >

Re: [Python-ideas] Pre-conditions and post-conditions

Total noob speaking here, but Those contracts are mostly important during development right ? Slowdown isn't that much of an issue during development. So you could make a debug mode that enforces the contracts, and a production mode that code users can use during production to stop the

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, @Paul Moore: thanks for pointing out that many people are not familiar with design-by-contract. I was not aware of that. Let me give you a very short introduction into contracts and what they are good for. I'll review some existing libraries and highlight what features we missed (and why we

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, 21 Aug 2018 at 11:27, Steven D'Aprano wrote: > > On Tue, Aug 21, 2018 at 09:06:54AM +0200, Marko Ristin-Kaufmann wrote: > > > Is there any chance to introduce these constructs in the language or is it > > too small a feature for such a big change? > > I don't think contracts is a small

Re: [Python-ideas] Pre-conditions and post-conditions

On Thu, Aug 16, 2018 at 4:19 PM Elazar wrote: > > You might also be interested in pep-563. although it is not intended for > design by contract, it can help (syntactically). > FYI, PEP 563 doesn't help it. Read this section:

Re: [Python-ideas] Pre-conditions and post-conditions

On Tue, Aug 21, 2018 at 09:06:54AM +0200, Marko Ristin-Kaufmann wrote: > Is there any chance to introduce these constructs in the language or is it > too small a feature for such a big change? I don't think contracts is a small feature. I think it is a HUGE feature, but under-appreciated by

Re: [Python-ideas] Pre-conditions and post-conditions

Hi, I had a look at the messages related to the PEP in question (PEP 316) in the archive. As far as I can tell, the main objection is that you can achieve contracts by implementing it with decorators. I think that these objections miss what actually Daniel Moisset wrote in his message: contracts

Re: [Python-ideas] Pre-conditions and post-conditions

pycontracts may be worth a look. https://andreacensi.github.io/contracts/ - @contract decorator, annotations, docstrings IDK if pycontracts supports runtime parameter validations that involve more than one parameter. Inheritance does appear to be supported, as are numpy array dimension

Re: [Python-ideas] Pre-conditions and post-conditions

I think that annotations were suggested because you could write an expression there without getting evaluated. I've thought about this problem many times in the past (as a Python dev with a long history working in Eiffel too) For me one of the crucial issue that is hard to translate into the

Re: [Python-ideas] Pre-conditions and post-conditions

Hi Jonathan and Paul, Thank you very much for your suggestions! I will try to contact the author of the PEP. Let me clarify a bit a potential misunderstanding. Please mind that contracts are not tied to individual variables, but to expressions. Think of it as defining a lambda which takes as

Re: [Python-ideas] Pre-conditions and post-conditions

On Thu, 16 Aug 2018 at 10:41, Jonathan Fine wrote: > > Hi Marko > > Thank you for introducing yourself, and clearly stating your question. > That helps us all. You asked: > > > Could somebody update me on the state of the discussion on this matter? > > I think bring the existing PEP up to date

Re: [Python-ideas] Pre-conditions and post-conditions

Hi Marko Thank you for introducing yourself, and clearly stating your question. That helps us all. You asked: > Could somebody update me on the state of the discussion on this matter? I think bring the existing PEP up to date would be a good starting point. Its content hasn't been changed since

Re: [Python-ideas] Pre-conditions and post-conditions

You might also be interested in pep-563 . although it is not intended for design by contract, it can help (syntactically). Elazar On Wed, Aug 15, 2018 at 11:07 PM Marko Ristin-Kaufmann < marko.ris...@gmail.com> wrote: > Hi, > > I would be very

[Python-ideas] Pre-conditions and post-conditions

Hi, I would be very interested to bring design-by-contract into python 3. I find design-by-contract particularly interesting and indispensable for larger projects and automatic generation of unit tests. I looked at some of the packages found on pypi and also we rolled our own solution