On Wed, Sep 26, 2018 at 7:59 AM Kyle Lahnakoski wrote:
> I use DbC occasionally to clarify my thoughts during a refactoring, and then
> only in the places that continue to make mistakes. In general, I am not in a
> domain that benefits from DbC.
>
> Contracts are code: More code means more bugs.
I use DbC occasionally to clarify my thoughts during a refactoring, and
then only in the places that continue to make mistakes. In general, I am
not in a domain that benefits from DbC.
Contracts are code: More code means more bugs. Declarative contracts are
succinct, but difficult to debug when w
On Wed, Sep 26, 2018 at 6:09 AM Lee Braiden wrote:
>
> Eh. It's too easy to cry "show me the facts" in any argument. To do that too
> often is to reduce all discussion to pendantry.
>
> That verifying data against the contract a function makes code more reliable
> should be self evident to anyo
Eh. It's too easy to cry "show me the facts" in any argument. To do that
too often is to reduce all discussion to pendantry.
That verifying data against the contract a function makes code more
reliable should be self evident to anyone with even the most rudimentary
understanding of a function cal
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.
>
>
> I don't know what you mean by "extraordinary" claim and "
e implementation of numpy.transpose() to figure 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:
performance
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:
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-Kaufmann writes:
>
>
Hi Robert,
You'll lose folks attention very quickly when you try to tell folk
> what they do and don't understand.
I apologize if I sounded offending, that was definitely not my intention. I
appreciate that you addressed that.
I suppose it's cultural/language issue and the wording was probably
#x27;s proposal doesn't necessarily require more syntax.
On Tue, Sep 25, 2018 at 8:00 AM 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
On 25/09/18 12:59, Hugh Fisher wrote:
Thank you for a very well thought out post, Hugh. I completely agree.
I just wanted to pull out one comment:
Adding new syntax or semantics to a programming language very often adds
accidental complexity.
This is, in my view, the main reason why the ba
> 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 not widely
> adopted?
[munch]
> Python is easier to write and read, and there are no libraries which are
> close in qu
> 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 not widely
> adopted?
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
[munch]
> Th
Angus Hollands writes:
> yes I'd pass in some kind of 'old' object as a proxy to the old object
> state.
Mostly you shouldn't need to do this, you can copy the state:
def method(self, args):
import copy
old = copy.deepcopy(self)
This is easy but verbose to do with a decora
Marko Ristin-Kaufmann writes:
> 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
Sorry, no. I was speaking as someone who is familiar with macros from
Lisp but doesn't miss them in Python,
On Mon, 24 Sep 2018 at 19:47, Marko Ristin-Kaufmann
wrote:
>
> Hi,
>
> Thank you for your replies, Hugh and David! Please let me address the points
> in serial.
>
> Obvious benefits
> You both seem to misconceive the contracts. The goal of the
> design-by-contract is not reduced to testing the c
Hi Mario,
yes I'd pass in some kind of 'old' object as a proxy to the old object
state.
My demo can handle function calls, unless they themselves ultimately call
something which can't be proxies e.g is instance (which delegates to the
test class, not the instance), or boolean evaluation of some ex
Hi Steve and others,
After some thinking, I'm coming to a conclusion that it might be wrong to
focus too much about how the contracts are written -- as long as they are
formal, easily transformable to another representation and fairly
maintainable.
Whether it's with a lambda, without, with "args"
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 an
Barry Scott writes:
> > @requires(lambda self, a, o: self.sum == o.sum - a.amount)
> > def withdraw(amount: int) -> None:
> > ...
> >
> > There is this lambda keyword in front, but it's not too bad?
>
> The lambda smells of internals that I should not have to care about
> being expos
Perhaps it’s because fewer Python functions involve transitioning between
states. Web development and statistics don’t involve many state transition.
State transitions are where I think I would find it useful to write contracts
out explicitly.
___
Pyth
> On 24 Sep 2018, at 20:09, Marko Ristin-Kaufmann
> wrote:
>
> 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
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 (
> On 23 Sep 2018, at 11:33, Hugh Fisher wrote:
>
> Could it be that Python has better libraries, is faster to develop for,
> attracts
> more programmers? If so, I suggest it's worth considering that this might
> be *because* Python doesn't have DbC.
I'm not sure how you get from the lack of D
> On 23 Sep 2018, at 11:13, Angus Hollands wrote:
>
> Hi Marko,
>
> I think there are several ways to approach this problem, though am not
> weighing in on whether DbC is a good thing in Python. I wrote a simple
> implementation of DbC which is currently a run-time checker. You could, with
for a wider audience), you
need to write down the contracts. Please see above where I tried to
explained that 2-5) are inferior approaches to documenting contracts
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 superio
> Date: Sun, 23 Sep 2018 07:09:37 +0200
> From: Marko Ristin-Kaufmann
> To: Python-Ideas
> Subject: [Python-ideas] Why is design-by-contracts not widely adopted?
[ munch ]
> *. *After properly reading about design-by-contract and getting deeper into
> the topic, there is no
Hi Marko,
I think there are several ways to approach this problem, though am not
weighing in on whether DbC is a good thing in Python. I wrote a simple
implementation of DbC which is currently a run-time checker. You could,
with the appropriate tooling, validate statically too (as with all
approac
On Sun, Sep 23, 2018, 1:10 AM Marko Ristin-Kaufmann
wrote:
> One explanation that seems plausible to me is that many programmers are
> actually having a hard time with formalization and logic rules (*e.g.,
> *implication,
> quantifiers), maybe due to missing education (*e.g. *many programmers ar
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 con
101 - 130 of 130 matches
Mail list logo
