On Thu, Oct 25, 2018, 14:44 Marko Ristin-Kaufmann
wrote:
>
> Nathaniel Smith wrote:
>
>> In your position, I wouldn't be talking to the core devs; I'd be
>> writing blog posts to proselytize the advantages of contracts, working
>> with popular projects that are interested in adopting them, writin
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 inc
A few thoughts:
1) Just as with with PEP 484, we could distinguish between contract
specification and checking. To achieve some of the goals that you state, we
need to standardise the way people would state contracts in their code (and
provide a small implementation in the stdlib, similar to the t
On Wed, Oct 24, 2018 at 11:23 AM, Marko Ristin-Kaufmann
wrote:
> I imagine that you conceive contracts purely as an approach to a testing to
> be applied to a single project. I'm not talking about that. I'm talking
> about two packages on pypi, both specifying contracts, each developed by a
> sepa
Chris Barker via Python-ideas writes:
> On Wed, Oct 24, 2018 at 12:57 AM, Chris Angelico wrote:
>
> > 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 rath
On Wed, Oct 24, 2018 at 12:57 AM, Chris Angelico wrote:
> 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?
>
I'm not (curre
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 vagueness
On Wed, Oct 24, 2018 at 9:08 PM Marko Ristin-Kaufmann
wrote:
>
> 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
>> li
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
> Roadblocks
> During the development, the following roadblocks were encountered:
>
> * We wanted to include the contracts in the output of help(). Unfortunately,
> help() renders the __doc__ of the class and not of the instance. For
> functions, this is the class "function" which you can not i
On Wed, Oct 24, 2018 at 6:41 PM Marko Ristin-Kaufmann
wrote:
> Next Steps?
> I personally doubt that we are enough people to form a party to push for a
> change in the language. A standardized library seems to me like a realizable
> compromise given the state of the discussion on this mail list.
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 contracts into
>
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 suppor
13 matches
Mail list logo
