Hi James,
I'm a bit short on time today, and would need some more time and attention
to understand the proposal you wrote. I'll try to come back to you
tomorrow.
In any case, I need to refactor icontract's decorators to use conditions
like lambda P: and lambda P, result: first before adding
On Sat, Sep 29, 2018 at 12:30:45PM +1200, Greg Ewing wrote:
> Chris Angelico wrote:
> >But as a part of the
> >function's declared intent, it's fine to have a postcondition of "the
> >directory will be empty" even though something could drop a file into
> >it.
>
> If you only intend the contract
I put the list of related discussion here, just in case.
Same suggestion:
https://mail.python.org/pipermail/python-dev/2005-July/054914.html
Idea for the "loop" keyword:
https://mail.python.org/pipermail/python-ideas/2014-June/028202.html
(followed by the same suggestion from @Random832:
On Sun, Sep 23, 2018 at 07:09:37AM +0200, Marko Ristin-Kaufmann wrote:
> After the discussion we had on the list and after browsing the internet a
> bit, I'm still puzzled why design-by-contract was not more widely adopted
> and why so few languages support it.
[...]
> *. *After properly reading
On 9/28/18 8:32 PM, Chris Angelico wrote:
On Sat, Sep 29, 2018 at 10:22 AM Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com> wrote:
On 9/28/18 7:39 PM, Steven D'Aprano wrote:
But none of that compares to C undefined behaviour. People who think
that they are equivalent, don't understand C
On 9/28/18 8:12 PM, Chris Angelico wrote:
On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing wrote:
Chris Angelico wrote:
It is still fundamentally difficult to make assertions about the file
system as pre/post contracts.
When you consider race conditions, I'd say it's impossible.
A postcondition
On Sat, Sep 29, 2018 at 10:22 AM Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 9/28/18 7:39 PM, Steven D'Aprano wrote:
> > But none of that compares to C undefined behaviour. People who think
> > that they are equivalent, don't understand C undefined behaviour.
>
> Well, yes:
Chris Angelico wrote:
But as a part of the
function's declared intent, it's fine to have a postcondition of "the
directory will be empty" even though something could drop a file into
it.
If you only intend the contract to serve as documentation,
I suppose that's okay, but it means you can't
On 9/28/18 7:39 PM, Steven D'Aprano wrote:
On Fri, Sep 28, 2018 at 07:18:54PM +0200, 2qdxy4rzwzuui...@potatochowder.com
wrote:
On 9/28/18 12:45 PM, Steven D'Aprano wrote:
On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote:
C and Python (currently) are known as simple languages.
On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing wrote:
>
> Chris Angelico wrote:
> > It is still fundamentally difficult to make assertions about the file
> > system as pre/post contracts.
>
> When you consider race conditions, I'd say it's impossible.
> A postcondition check involving the file system
> Date: Sat, 29 Sep 2018 02:45:06 +1000
> From: Steven D'Aprano
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Why is design-by-contracts not widely
> Message-ID: <20180928164506.gn19...@ando.pearwood.info>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Sep 25, 2018 at
On Fri, Sep 28, 2018 at 07:18:54PM +0200, 2qdxy4rzwzuui...@potatochowder.com
wrote:
>
> On 9/28/18 12:45 PM, Steven D'Aprano wrote:
> >On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote:
> >
> >>C and Python (currently) are known as simple languages.
> >
> >o_O
> >
> >That's a usage of
Many editors highlight decorators in a different color that makes it easier to
ignore and can also fold decorators.
Contracts can also sometimes actively improve the flow of code.
I personally find a formal contract easier to read than informal documentation.
It also reduces the times where
Let’s get some ideas for how icontract can say “it should throw an exception if
this happens.”
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
> The problem with readability might be easier to solve than I thought, and
> your pointer to coconut gave me the idea. What if we make a utility that
> takes the python source code, examines the decorators pre/post/inv (or
> whatever we call them) and transforms them back and forth from/to
I am fine with your proposed syntax. It’s certainly lucid. Perhaps it would be
a good idea to get people accustomed to “non-magic” syntax.
> I still have a feeling that most developers would like to store the state in
> many different custom ways.
Please explain. (Expressions like thunk(all)(a
Chris Angelico wrote:
It is still fundamentally difficult to make assertions about the file
system as pre/post contracts.
When you consider race conditions, I'd say it's impossible.
A postcondition check involving the file system could fail
even if the function does its job perfectly.
--
Greg
On 2018-09-28 05:23, David Mertz wrote:
On Thu, Sep 27, 2018, 9:25 PM Marko Ristin-Kaufmann
mailto:marko.ris...@gmail.com>> wrote:
Try to question whether the contracts I wrote are so obvious to
everybody even if they are obvious to you and keep in mind that the
user does not look
On 9/28/18 12:45 PM, Steven D'Aprano wrote:
On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote:
C and Python (currently) are known as simple languages.
o_O
That's a usage of "simple" I haven't come across before. Especially in
the case of C, which is a minefield of
On Tue, Sep 25, 2018 at 09:59:53PM +1000, Hugh Fisher wrote:
> C and Python (currently) are known as simple languages.
o_O
That's a usage of "simple" I haven't come across before. Especially in
the case of C, which is a minefield of *intentionally* underspecified
behaviour which makes it near
Hi,
(Posting from work, so sorry for the short response.)
@Paul Moore icontract.pre/post/inv have the enabled
argument; if not enabled, the contract is ignored.
Similarly with rmdir() -- "the directory must be empty" -- but how exactly
>> am I supposed to check that?
>>
>
> Isn't that the
On Fri, 28 Sep 2018 at 13:23, David Mertz wrote:
> I agree that all the Sphinx documentation examples shown are very nice. Prose
> descriptions would often be nicer still, but the Boolean expressions are
> helpful for those unusual cases where I don't want to look at the code.
I'm ambivalent
On Thu, Sep 27, 2018, 9:25 PM Marko Ristin-Kaufmann
wrote:
> Try to question whether the contracts I wrote are so obvious to everybody
> even if they are obvious to you and keep in mind that the user does not
> look into the implementation.
>
I had missed this comment, but this seems to be the
On Fri, Sep 28, 2018, 4:38 AM Paul Moore wrote:
> On Fri, 28 Sep 2018 at 02:24, Marko Ristin-Kaufmann <
> marko.ris...@gmail.com> wrote:
>
>> I annotated pathlib with contracts:
>> https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML docs
>> into
>>
On Fri, 28 Sep 2018 at 10:37, Chris Angelico wrote:
>
> On Fri, Sep 28, 2018 at 7:29 PM Jonathan Fine wrote:
> >
> > I like this discussion. I'd like to add another theme, namely what
> > should happen when there is an error. (This is prompted by race
> > hazards when performing file system
On Fri, Sep 28, 2018 at 7:29 PM Jonathan Fine wrote:
>
> I like this discussion. I'd like to add another theme, namely what
> should happen when there is an error. (This is prompted by race
> hazards when performing file system operations.)
>
> Suppose fn_a() calls fn_b(), and fn_b() raises an
I like this discussion. I'd like to add another theme, namely what
should happen when there is an error. (This is prompted by race
hazards when performing file system operations.)
Suppose fn_a() calls fn_b(), and fn_b() raises an exception. What then
should fn_a() do? It may be that this
On Fri, Sep 28, 2018 at 11:25 AM Marko Ristin-Kaufmann
wrote:
>
> Hi,
>
> I annotated pathlib with
> contracts:https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML
> docs into
> https://github.com/mristin/icontract-pathlib-poc/blob/master/contracts-pathlib-poc.zip,
> you can
On Fri, Sep 28, 2018 at 6:56 PM Jonathan Fine wrote:
> Finally, I note
>
> >>> a = 2
> >>> a **= 3
> >>> a
> 8
>
? Yes? That's what 2 ** 3 is, so that's what I would expect.
All other augmented assignment operators take an assignment target on
the left and a (single) value on the right.
ChrisA
Summary: I recast an example in a more abstract form.
Steve D'Aprano wrote:
> Think about a more complex assignment:
>text .= encode(spam) + str(eggs)
I find this example instructive. I hope the following is also instructive:
$ python3
>>> obj += incr
NameError: name 'obj' is not defined
On Fri, 28 Sep 2018 at 02:24, Marko Ristin-Kaufmann
wrote:
> Hi,
>
> I annotated pathlib with contracts:
> https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML docs
> into
> https://github.com/mristin/icontract-pathlib-poc/blob/master/contracts-pathlib-poc.zip,
> you can just
On Fri, Sep 28, 2018 at 05:34:58PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >Think about a more complex assignment:
> >
> >text .= encode(spam) + str(eggs)
>
> I think the only sane thing would be to disallow that, and
> require the RHS to have the form of a function call, which is
I had the number 4 in mind
Though I think your idea is way better, as it's more flexible and less
confusing
On Fri, Sep 28, 2018, 10:33 Brice Parent wrote:
>
> Le 27/09/2018 à 12:48, Ken Hilton a écrit :
>
> Hi Jasper,
> This seems like a great idea! It looks so much cleaner, too.
>
> Would
Le 27/09/2018 à 12:48, Ken Hilton a écrit :
Hi Jasper,
This seems like a great idea! It looks so much cleaner, too.
Would there be a dunder method handling this? Or since it's explicitly
just a syntax for "obj = obj.method()" is that not necessary?
My only qualm is that this might get PHP
34 matches
Mail list logo
