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 <=
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
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
>
;", line 1, in
> > AttributeError: type object 'tuple' has no attribute '__iadd__'
> > type object 'tuple' has no attribute '__iadd__'
> > >>> tuple.__add__
> >
> > >>> list.__iadd__
> >
> > >>> list.__add__
&g
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.
>
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
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"
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
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
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
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)
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
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, 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-
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
>
>
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
James has suggested that Python be enhanced so that
>>> a, b += c, d
is a short-hand for
>>> a += c
>>> b += d
Myself, James and Matthew wrote
>> > Does it IN PRACTICE bring sufficient benefits to users?
>> I found myself needing this when I was writing a monte-carlo
>> simulation in python
17 matches
Mail list logo
