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 slowdow
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
>
> Thos
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-
condition
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
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 i
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) sta
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 s
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 a
Hello,
the PEP 420 (Implicit Namespace Packages) is quite descriptive about the
problem and the solution implemented back in Python 3.3 but I feel there
may be a part missing (but maybe this is categorized as an
implementation detail).
As I understand, for a package to allow being extended i
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" but
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 large
On Fri, 24 Aug 2018 at 18:18 Mike Barnett wrote:
> It’s fascinating just how many packages are being dragged out for
> examination or clobbering other than the one that I asked for
> assistance/help on.
>
>
>
> I see the code of conduct link in the thread. Perhaps a review would be
> helpful.
>
> > Traceback (most recent call last):
> > File "", line 1, in
> > AttributeError: type object 'tuple' has no attribute '__iadd__'
> > type object 'tuple' has no attribute '__iadd__'
> > >>> tuple.
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
>
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 so
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 <= pqry.
16 matches
Mail list logo
