[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

Hi, > I mean, as shown in this example and a previous one I posted a screenshot > of, I think it's cute and geeky to use a few math symbols in the same way > in my editor. I've been doing that for a few years, and it never got > beyond "slightly cute." > I would second this. I find it

[Python-ideas] Re: Need a core developer sponsor for a PEP

Hi Philippe, Thanks for preparing the PEP! I also think it will improve the readability a lot in code that heavily uses type annotations. I'd suggest you to split this PEP in two: one for Union types and another one for Optional. It will facilitate the discussions and reaching consensus since

Re: [Python-ideas] Discussion: Duck typing with “concepts”

Hi James, As Ivan has mentioned, Protocols already allow for statical type checks: https://mypy.readthedocs.io/en/latest/protocols.html We didn't need protocols that often at Parquery, maybe half a dozen of times? While we didn't use them in Python, we had to use them intensively in Go where it

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

Hi Abe, I agree. That's why I prefaced this topic with [Brainstorm]. I want to > explore the solution space to this problem and discuss some of the pros and > cons of different ideas, *not* proceed straight to action. You are right. Please apologize, I was so primed by the discussions we had

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

de-simple/> overlaps > some with the role of invariants. I don't know what to do with that > knowledge, but it seems like it might be useful. > > Anyway, I hope those half-baked thoughts have *some* value... > > On Wed, Nov 28, 2018 at 1:12 AM Marko Ristin-Kaufmann < >

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

Hi, Property based testing is not about just generating random values till the > heath death of the universe, but generating sensible values in a > configurable way to cover all equivalence classes we can think of. if my > function takes two floating point numbers as arguments, hypothesis >

Re: [Python-ideas] [Brainstorm] Testing with Documented ABCs

Hi Abe, I've been pulling a lot of ideas from the recent discussion on design by > contract (DBC), the elegance and drawbacks > of doctests > , and the amazing talk >

Re: [Python-ideas] Contracts in python -- a report & next steps

Hi, Stephen J. Turnbull wrote: > You can't weaken the > contracts for iparent.recontract as far as I can see in a decorator- > based contract library Of course you can weaken the contracts for iparent.recontract with a decorator-based contract library. From my first message: > The features

Re: [Python-ideas] Contracts in python -- a report & next steps

Hi Chris, If not, all your proposed benefits can be achieved at the level of a > single project, by just saying "we're going to use THIS contracts > library", unless I'm misunderstanding something here. > I think we are having a big disconnect in the discussion. Please apologize for my

Re: [Python-ideas] Contracts in python -- a report & next steps

Hi Chris, For the sake of those of us who REALLY don't feel like diving back > into the extensive threads on this subject, can you please summarize > the benefits of having this in the stdlib rather than as a third-party > library? > Certainly. We need a standard approach to contracts as opposed

Re: [Python-ideas] Contracts in python -- a report & next steps

P.S. Here is the link to the github repo: https://github.com/Parquery/icontract On Wed, 24 Oct 2018 at 09:40, Marko Ristin-Kaufmann wrote: > Hi, > I would like to give you a short report on the development of icontract > library following the discussion about the introduction of

[Python-ideas] Contracts in python -- a report & next steps

Hi, I would like to give you a short report on the development of icontract library following the discussion about the introduction of contracts into Python (e.g., see [1, 2, 3, 4]). *Features* The functionality of icontract library is basically on par with Eiffel, Cobra and other languages

Re: [Python-ideas] Multi Statement Lambdas

Hi, What about writing longer map in pyspark? When I worked with Spark and Scala, it was easy to script a longer chain of transformations in Scala. Does anybody know how that works in Python without multiline lambdas? Cheers Marko Le dim. 21 oct. 2018 à 18:40, Ron Reiter a écrit : >

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

between the two. > > > > Do we? I haven't noticed anything that matches that description, > > although I admit I haven't read every single post in these threads > > religiously. > > Try this: > > On Mon, Oct 8, 2018 at 5:11 PM Marko Ristin-Kaufmann > wrote: > >

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi Crhis, > In other words, you change the *public interface* of your functions > > all the time? How do you not have massive breakage all the time? > > I can't comment about Marko's actual use-case, but *in general* > contracts are aimed at application *internal* interfaces, not so much >

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

yle) and unit, integration and end-to-end tests, so actually unexpected breakages in production are not that frequent. What does happen often, though, is that documentation gets stale. Cheers, Marko On Mon, 8 Oct 2018 at 07:29, Chris Angelico wrote: > On Mon, Oct 8, 2018 at 4:26 PM Marko Ristin-Ka

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

uot; integration tests rather than none). Cheers, Marko On Sun, 30 Sep 2018 at 08:17, Marko Ristin-Kaufmann wrote: > Hi, > > I compiled a couple of issues on github to provide a more structured > ground for discussions on icontract features: > https://github.com/Parquery/ic

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

ote: > On 9/24/2018 3:46 AM, Marko Ristin-Kaufmann wrote: > > I am responding to your request "Please do point me to what is not > obvious to you". I think some of your claims are not only not obvious, > but are wrong. I have read some (probably less than half) of the >

Re: [Python-ideas] Dynamic getting of __doc__ of a function

Hi Steve, > > * built-in class function ignoring the property getter (some_func.__doc__ > > set to a property returns the property instead of invoking the getter) > > Not just functions, it is all instances. Properties are only invoked if > they are on the class object, not the instance. > I

Re: [Python-ideas] Dynamic getting of __doc__ of a function

Hi, @Jonathan: thanks! I'll have a look at your links. So there are actually two issues if I understand correctly: * help() ignoring the property getter when invoked on an instance * built-in class function ignoring the property getter (some_func.__doc__ set to a property returns the property

Re: [Python-ideas] Dynamic getting of __doc__ of a function

On Mon, Oct 8, 2018 at 1:41 AM Marko Ristin-Kaufmann > wrote: > > (If you wonder about the use case: I'd like to dynamically generate the > docstrings when functions are decorated with contracts from icontract > library. Condition functions need to be parsed and re-formatted, so this

Re: [Python-ideas] Dynamic getting of __doc__ of a function

overhead during the decoration since normal course of program operation does not need pretty-printed contracts.) Thanks for any pointers! Please let me know if you'd like me to compress one or the other example or explain something in more detail. Cheers, Marko On Sun, 7 Oct 2018 at 11:07, Steven D'Apr

[Python-ideas] Dynamic getting of __doc__ of a function

Hi, I'm working on decorators that have a dynamic __doc__ property computed at runtime and not at decoration time. The decorator must return the wrapper as a function and can not return a callable object with __call__ since the "self" argument would not be properly passed through the decorator.

Re: [Python-ideas] Transpiling contracts

; > --Ned. > > On 10/2/18 1:14 AM, Marko Ristin-Kaufmann wrote: > > Hi James, > > I had another take at it. I wrote it down in the github issue ( > https://github.com/Parquery/icontract/issues/48#issuecomment-426147468): > > SLOW=os.environ.get("SOME_ENVIRONMENT_VARIA

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

Hi Steven (D'Aprano), Right now, that choice is very restrictive, and I personally don't like > the look and feel of existing contract libraries. I would give my right > eye for Cobra-like syntax for contracts in Python: > > http://cobra-language.com/trac/cobra/wiki/Contracts > You might be

Re: [Python-ideas] Transpiling contracts

lf.name) > @post(var=R.attr == P.old.var) > > The decorator can also check the type of the returned object, and if it’s > MockP it will use MockP protocol and otherwise it will check the object is > callable and treat it as a lambda. > > Your approach has better type hinting, b

Re: [Python-ideas] Renaming icontract to pcontract

mal and not worth the hassle of > renaming to pcontract. People would just say “Python icontract” when it’s > ambiguous. > > Sent from my iPhone > > On Oct 1, 2018, at 3:28 AM, Marko Ristin-Kaufmann > wrote: > > Hi Cameron, > A nerdy way to make it sound like a sentence: "I c

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

Hi Steve (Turnbull), It sounds to me like the proof of the pudding for Python will be > annotating the ABC module with contracts. If that turns out to be a > mostly fruitless exercise, it's hard to see how "real" contracts > (vs. using asserts to "program in contracting style") are an important

Re: [Python-ideas] Renaming icontract to pcontract

Hi Cameron, A nerdy way to make it sound like a sentence: "I contract that ...". Pcontract would stand for python contract. Pycontract is already taken. Cheers, Marko Le lun. 1 oct. 2018 à 09:15, Cameron Simpson a écrit : > On 01Oct2018 07:25, Marko Ristin-Kaufmann wrote

[Python-ideas] Renaming icontract to pcontract

Hi, I'd like to rename icontract into pcontract to avoid name conflict with java's icontract library. Do you have any better suggestion? Thanks! Marko ___ Python-ideas mailing list Python-ideas@python.org

[Python-ideas] Transpiling contracts

Hi James, Regarding the “transpile into Python” syntax with with statements: Can I > see an example of this syntax when used in pathlib? I’m a bit worried this > syntax is too long and “in the way”, unlike decorators which are before the > function body. Or do you mean that both MockP and your

Re: [Python-ideas] "old" values in postconditions

> > I suspect this would deal better with VCS. > > This syntax does have a a nice visual alignment. I’m not entirely sure > what kind of indentation PEP 8 recommends and editors give, so the point > may be moot if the natural indentation also gives the same visual alignm

Re: [Python-ideas] "old" values in postconditions

the discussion into a new email thread, we keep > the latest agreed upon proposal on GitHub issues. > > On Sun, Sep 30, 2018 at 4:32 PM Marko Ristin-Kaufmann < > marko.ris...@gmail.com> wrote: > >> Hi James, >> (I'm just about to go to sleep, so I'll answer th

Re: [Python-ideas] "old" values in postconditions

Hi James, (I'm just about to go to sleep, so I'll answer the other messages tomorrow.) Should we keep some kind of document to keep track of all the different > proposals? I’m thinking an editable document like HackMD where we can label > all the different ideas to keep them straight in our head.

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

Hi Cameron, Just a word of caution: I made a mistake and badly designed interface to icontract. It will change in the near future from: @post(lambda arg1, arg2, result: arg1 < result < arg2) most probably to: @ensures(lambda P: P.arg1 < result < P.arg2) This avoids any name conflicts with

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi, I compiled a couple of issues on github to provide a more structured ground for discussions on icontract features: https://github.com/Parquery/icontract/issues (@David Maertz: I also included the issue with automatically generated __doc__ in case you are still interested in it). Cheers,

Re: [Python-ideas] "old" values in postconditions

and have separate threads with code highlighting etc. Is that OK with you? Cheers, Marko On Sat, 29 Sep 2018 at 21:22, Marko Ristin-Kaufmann wrote: > Hi James, > I reread the proposal with MockP. I still don't get the details, but if I > think I understand the basic idea. You put a pl

Re: [Python-ideas] "old" values in postconditions

bj): > ># create a MockP object from a value. Generate a random identifier > and set that as the key in symtable, the AST node is the name of that > identifier, retrieving its value through simple expression evaluation. > >... > > > thunk = MockP.wrap_va

Re: [Python-ideas] "old" values in postconditions

n the body of if-statement. This is later at back-conversion to python easy to transform into a lambda. Cheers, Marko Le sam. 29 sept. 2018 à 20:56, Marko Ristin-Kaufmann a écrit : > Hi James, > Just a PS to the previous syntax: > > with contracts: > with preconditions: > a

Re: [Python-ideas] "old" values in postconditions

rved for the result of the function. No statements allowed in require/ensure. The same with class invariants. Works with ast and autocomplete in pycharm. Sorry for the hasty message :) Marko Le sam. 29 sept. 2018 à 07:36, Marko Ristin-Kaufmann a écrit : > Hi James, > I'm a bit short on t

Re: [Python-ideas] "old" values in postconditions

t; > thunk = MockP.wrap_value > > P = MockP('P') > > # elsewhere: ensure P is only accessed via valid “dot attribute access” > inside @snapshot so contracts fail early, or don’t and allow Magic like > __dict__ to occur on P. > > On Sep 27, 2018, at 9:49 PM, Marko Ristin-Ka

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi, (Posting from work, so sorry for the short response.) @Paul Moore icontract.pre/post/inv have the enabled argument; if not enabled, the contract is ignored. Similarly with rmdir() -- "the directory must be empty" -- but how exactly >> am I supposed to check that? >> > > Isn't that the

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

only on the content. We are still talking about contracts in general, not about the concrete contract implementation. Cheers, Marko On Thu, 27 Sep 2018 at 11:37, Marko Ristin-Kaufmann wrote: > Hi Paul, > I only had a contracts library in mind (standardized so that different > modules w

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi Paul, I only had a contracts library in mind (standardized so that different modules with contracts can interact and that the ecosystem for automic testing could emerge). I was never thinking about the philosophy or design methodology (where you write _all_ the contracts first and then have the

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

that the interface to icontract might change soon so I'd wait a month or two before it stabilizes. Cheers, Marko Le mer. 26 sept. 2018 à 20:12, David Stanek a écrit : > On Wed, Sep 26, 2018 at 12:49 AM Marko Ristin-Kaufmann > wrote: > > > >> An extraordinary claim is like "DbC

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

over as arrogant due to limits of the medium. It was not my intention to sound so. I'll have a look at pathlib then. Cheers, Marko Le mer. 26 sept. 2018 à 15:15, Paul Moore a écrit : > On Wed, 26 Sep 2018 at 14:04, Marko Ristin-Kaufmann > wrote: > > > > @Chris Angelico

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

hat contracts are useful? Is it general enough to start with? On Wed, 26 Sep 2018 at 14:58, Paul Moore wrote: > On Wed, 26 Sep 2018 at 13:40, Marko Ristin-Kaufmann > wrote: > > > Please mind that I said: any library would benefit from it, as in the > users of any library on pipy

Re: [Python-ideas] "old" values in postconditions

ument.some_attr)) > @snapshot(lambda _,some_identifier, other_identifier: > some_func(_.some_argument.some_attr), other_func(_.self)) > > I like #A4 the most because it’s fairly DRY and avoids the extra > punctuation of > > @capture(lambda a: {"some_identifier&quo

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

, but it's at least better than no estimate. We can have as little as 10 functions for the start. Hopefully a couple of other people would join, so then we can even see what the variance of contracts would look like. On Wed, 26 Sep 2018 at 14:40, Marko Ristin-Kaufmann wrote: > Hi Chris and P

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

* verifiable documentation * deeper testing (every test case tests also other parts of the system, akin to asserts) * automatic test generation * hand-break akin to asserts I find the first one, verifiable documentation, to be the most useful one in working with my team at the moment. Cheers, Marko On Wed,

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

hat actually displays the figure could ensure that the "displayed" property of the figure is set and that the window associated with the figure is visible. Cheers, Marko On Wed, 26 Sep 2018 at 09:19, Chris Angelico wrote: > On Wed, Sep 26, 2018 at 5:10 PM Marko Ristin-Kaufmann &g

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

evious message -- could you maybe say what would convince you that enough projects would actually benefit from formal contracts? Cheers, Marko On Wed, 26 Sep 2018 at 07:40, Chris Angelico wrote: > On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann > wrote: > > > > Hi Chris, >

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi Chris, It's easy to show beautiful examples that may actually depend on other > things. Whether that's representative of all contracts is another > question. I agree. There are also many contracts which are simply too hard to write down formally. But many are also easily captured in formal

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

pp for you team, an Android app for your startup, > fraud software, and Facebook make different accounting decisions. I > contend most code projects can not justify DbC. > > > On 2018-09-24 03:46, Marko Ristin-Kaufmann wrote: > > When you are documenting a method you have the fo

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

ico wrote: > On Wed, Sep 26, 2018 at 3:19 AM Marko Ristin-Kaufmann > wrote: > >> Claiming that DbC annotations will improve the documentation of every > >> single library on PyPI is an extraordinary claim, and such claims > >> require extraordinary proof. &

Re: [Python-ideas] "old" values in postconditions

s/properties. In documentation, I'd list all the captures of both ancestor and the current class. I'm looking forward to reading your opinion on this and alternative suggestions :) Marko On Tue, 25 Sep 2018 at 18:12, Franklin? Lee wrote: > On Sun, Sep 23, 2018 at 2:05 AM Marko Ristin-Kaufma

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

re out what happens when transposing a N-D array. Cheers, Marko On Tue, 25 Sep 2018 at 13:13, Hugh Fisher wrote: > > Date: Mon, 24 Sep 2018 09:46:16 +0200 > > From: Marko Ristin-Kaufmann > > To: Python-Ideas > > Subject: Re: [Python-ideas] Why is design-by-contracts no

Re: [Python-ideas] "old" values in postconditions

Hi James and Franklin, getsource() definitely does not work. I tried for a long, long time to make it work and finally gave up. I parse in icontract the whole file where the lambda function resides and use asttokens to locate the node of the lambda (along some tree traversing upwards and making

Re: [Python-ideas] Why is design-by-contracts not widely

ce is important so that slow execution is not an argument against the formal contracts. Cheers, Marko On Tue, 25 Sep 2018 at 14:01, Hugh Fisher wrote: > > Date: Mon, 24 Sep 2018 09:46:16 +0200 > > From: Marko Ristin-Kaufmann > > To: Python-Ideas > > Subject: Re: [Python-id

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi Steve, I'll give it a shot and implement a proof-of-concept icontrac-macro library based on macropy and see if that works. I'll keep you posted. Cheers, Marko On Tue, 25 Sep 2018 at 12:08, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Marko Ristin-Kaufma

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

find a better way to contribute to the discussion. Cheers, Marko On Tue, 25 Sep 2018 at 10:01, Robert Collins wrote: > On Mon, 24 Sep 2018 at 19:47, Marko Ristin-Kaufmann > wrote: > > > > Hi, > > > > Thank you for your replies, Hugh and David! Please let me a

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

the raw form of the contracts, but as long as syntax is pragmatic, I don't expect this to be a blocker. Is this a sane focus? Cheers, Marko On Tue, 25 Sep 2018 at 08:18, Marko Ristin-Kaufmann wrote: > Hi Steve, > Thanks a lot for pointing us to macropy -- I was not aware of the library,

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi Steve, Thanks a lot for pointing us to macropy -- I was not aware of the library, it looks very interesting! Do you have any experience how macropy fit with current IDEs and static linters (pylint, mypy)? I fired up pylint and mypy on the sample code from their web site, played a bit with it

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Hi Barry, I think the main issue with pyffel is that it can not support function calls in general. If I understood it right, and Angus please correct me, you would need to wrap every function that you would call from within the contract. But the syntax is much nicer than icontract or dpcontracts

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

compared to 1). As I wrote above, I would be very, very thankful if you point me to other approaches (apart from 1-5) that are superior to contracts or state an argument why approaches 2-5) are superior to the contracts since that is what I miss to see. Cheers, Marko On Sun, 23 Sep 2018 a

[Python-ideas] "old" values in postconditions

Hi, (I'd like to fork from a previous thread, "Pre-conditions and post-conditions", since it got long and we started discussing a couple of different things. Let's discuss in this thread the implementation of a library for design-by-contract and how to push it forward to hopefully add it to the

[Python-ideas] Why is design-by-contracts not widely adopted?

Hi, (I'd like to fork from a previous thread, "Pre-conditions and post-conditions", since it got long and we started discussing a couple of different things. Let's put the general discussion related to design-by-contract in this thread and I'll spawn another thread for the discussion about the

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

is there any blocker left why you would *not *use the contracts in your code? Anything I could improve or fix in icontract that would make it more convincing to use (apart from implementing static contract checking and automatic test generation :))? Cheers, Marko On Thu, 20 Sep 2018 at 22:52, M

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

ot; pass @staticmethod @abc.abstractmethod @icontract.post(lambda result: all(not pth.is_absolute() for pth in result)) def dirs(config: mapried.config.Config) -> List[pathlib.Path]: """ Get directories used by this component. :param co

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

ur invariants, and a > testing library extracts that information and uses it to automatically > synthesize interesting test cases. > > (And of course, what would be very cool is if the contracts could be > verified statically like you can do in languages like dafny -- that way, > you g

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

standard libraries? Any thoughts or feedback on the icontract library in general? Cheers, Marko On Mon, 10 Sep 2018 at 09:29, Marko Ristin-Kaufmann wrote: > Hi, > > I implemented the inheritance via meta classes and function and class > attributes for pre/postconditions an

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

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 inheri

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

standard library would do it for me as a compromise -- it would standardize, even if in ugly way (as Steven D'Aprano pointed out), how we deal with contracts in Python and would allow for integration into IDEs and static analysis tools. On Thu, 30 Aug 2018 at 05:01, Ethan Furman wrote: > On 08/29

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

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

o the >> DbC idea where the asbtraction/interface of the class is conceptually >> separate and has independent information wrt to the runtime objects. >> >> >> On 16 August 2018 at 18:49, Marko Ristin-Kaufmann > > wrote: >> >>> Hi Jonathan and

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

[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

[Python-ideas] Hi!

Hi, Please let me briefly introduce myself. I'm Marko and live in Zurich, Switzerland. I learned Python and Django during an intership in 2007 and followed its development ever since. I did research in computer vision (at ETH Zurich) and now I work at Parquery AG (Zurich, Switzerland) where we