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
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_VARIABLE", "") != ""
class SomeClass:
def __init__(self)->None:
self.some_prop = 1984
def
Ok, let's keep icontract as it was already referenced a couple of times at
least on this list.
I'll rename the pypi package to icontract2 and the module as well as soon
as I change the interface.
On Mon, 1 Oct 2018 at 20:43, James Lu wrote:
> I think the confusion would be minimal and not
On Mon, Oct 1, 2018, 9:13 PM Steven D'Aprano wrote:
> For an application, it doesn't matter if my function sets the computer on
> fire when passed the string "fish", if there is no way for the application
> to pass that string to the function. If it can't happen, it can't happen
> and there's no
On Tue, Oct 02, 2018 at 02:43:57AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > I'm not sure how Stephen went from my comment that you can't unit test
> > loop invariants to the idea that loop invariants aren't in the
> > implementation.
>
> Obviously I didn't. I went
On Mon, Oct 01, 2018 at 12:36:18PM -0400, David Mertz wrote:
> There's some saying/joke about software testing along the lines of:
>
> For an argument that should be in range 1-100:
> try 50; try 1; try 100
> try 101; try 0;
> try -1,
> try 3.14
> try 1+1j;
> try the string "fish",
>
I think the confusion would be minimal 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
Marko Ristin-Kaufmann writes:
> Do you mean annotating an abstract class with contracts or
> annotating the actual functions in abc module?
I mean the functions in the abc module.
> Inheriting of contracts also proved useful when you define an
> interface as a group of functions together
Steven D'Aprano writes:
> I'm not sure how Stephen went from my comment that you can't unit test
> loop invariants to the idea that loop invariants aren't in the
> implementation.
Obviously I didn't. I went from your statement that (1) contracts are
separated from the implementation and
On Sun, Sep 30, 2018 at 11:34 AM Steven D'Aprano
wrote:
> On Sun, Sep 30, 2018 at 10:29:50AM -0400, David Mertz wrote:
> But given that in general unit tests tend to only exercise a handful of
> values (have a look at the tests in the Python stdlib) I think it is
> fair to say that in practice
On Sun, Sep 30, 2018 at 06:33:08PM +1000, Chris Angelico wrote:
> On Sun, Sep 30, 2018 at 6:03 PM Steven D'Aprano wrote:
> >
> > On Sun, Sep 30, 2018 at 02:50:28PM +1000, Chris Angelico wrote:
> >
> > > And yet all the examples I've seen have just been poor substitutes for
> > > unit tests. Can
Hi Marko,
I’m going to refer to the transpiler syntax as “block syntax.”
1. How does Eiffel do formal contracts?
2. What’s the use case for preferring block syntax over lambda syntax? Is the
block syntax only better when multiple statements are needed to test a single
contract condition?
2.
On Sun, Sep 30, 2018 at 06:19:11PM -0400, Eric V. Smith wrote:
> On 9/30/2018 8:11 AM, Stephen J. Turnbull wrote:
> >Steven D'Aprano writes:
> > > (7) You can't unit test loop invariants
> >
> >I don't see how a loop invariant can be elegantly specified without
> >mixing it in to the
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
Elazar writes:
> On Sun, Sep 30, 2018, 15:12 Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > What does "inherited" mean? Just that methods that are not overridden
> > retain their contracts?
>
> Contracts are attached to interfaces, not to specifications. So
>
On 2018-09-30 10:45, Anders Hovmöller wrote:
>
>>> I am roughing out such a class and some test cases which will hopefully
>>> include some cases where the hoped for advantages can be realised.
>>>
>>> My thinking on bitwise operations is to do the same as arithmetic
>>> operations, i.e.
Hi Steve
You've suggested that we add to Python an integer NaN object, similar
to the already existing float NaN object.
>>> x = float('nan')
>>> x, type(x)
(nan, )
I've learnt that decimal also has a NaN object, but not fractions.
https://stackoverflow.com/questions/19374254/
>>> from decimal
On Mon, 1 Oct 2018 at 00:00, Chris Angelico wrote:
>
> On Mon, Oct 1, 2018 at 8:53 AM Oscar Benjamin
> wrote:
> >
> > On Sun, 30 Sep 2018 at 02:01, Steven D'Aprano wrote:
> > >
> > > On Sat, Sep 29, 2018 at 09:43:42PM +0100, Oscar Benjamin wrote:
> > > > On Sat, 29 Sep 2018 at 19:38, Steve
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:
> >I'd like to
On 01Oct2018 07:25, Marko Ristin-Kaufmann wrote:
I'd like to rename icontract into pcontract to avoid name conflict with
java's icontract library.
Do you have any better suggestion?
No, sounds ok to me. What was the "i" for in the old name?
Cheers,
Cameron Simpson
20 matches
Mail list logo
