Re: [Python-ideas] Suggestion: Extend integers to include iNaN

2018-09-28 Thread Nathaniel Smith
On Fri, Sep 28, 2018 at 11:31 PM, Steve Barnes wrote: > One specific use case that springs to mind would be for Libraries such > as Pandas to return iNaN for entries that are not numbers in a column > that it has been told to treat as integers. Pandas doesn't use Python objects to store integers,

[Python-ideas] Suggestion: Extend integers to include iNaN

2018-09-28 Thread Steve Barnes
One of the strengths of the IEEE float, (to set against its many weaknesses), is the presence of the magic value NaN. Not a Number, or NaA, is especially useful in that it is a valid value in any mathematical operation, (always returning NaN), or comparison, (always returning False). In functio

Re: [Python-ideas] "old" values in postconditions

2018-09-28 Thread Marko Ristin-Kaufmann
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 snapsh

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Steven D'Aprano
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 t

Re: [Python-ideas] "while:" for the loop

2018-09-28 Thread Mikhail V
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: https://

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Steven D'Aprano
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

Re: [Python-ideas] Why is design-by-contracts not widely

2018-09-28 Thread Dan Sommers
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 undefi

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Dan Sommers
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 c

Re: [Python-ideas] Why is design-by-contracts not widely

2018-09-28 Thread Chris Angelico
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: Some

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Greg Ewing
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 tur

Re: [Python-ideas] Why is design-by-contracts not widely

2018-09-28 Thread Dan Sommers
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. o

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Chris Angelico
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

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

2018-09-28 Thread Hugh Fisher
> 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 09:59

Re: [Python-ideas] Why is design-by-contracts not widely

2018-09-28 Thread Steven D'Aprano
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 "

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread James Lu
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 y

[Python-ideas] Exception handling in contracts

2018-09-28 Thread James Lu
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: http://python.org/psf/codeofconduc

Re: [Python-ideas] "old" values in postconditions

2018-09-28 Thread James Lu
> 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 vali

Re: [Python-ideas] You might find coconut language useful

2018-09-28 Thread James Lu
Hi Marko, I honestly don’t know how many people are using coconut. Though with a little bit of configuring Python’s import functionality, it should have decent inter compatibility. Even without Coconut, I still find icontract’s plain Python lambda syntax readable and useful. James Lu > On Se

Re: [Python-ideas] "old" values in postconditions

2018-09-28 Thread James Lu
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

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Greg Ewing
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

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Brendan Barnwell
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 in

Re: [Python-ideas] Why is design-by-contracts not widely

2018-09-28 Thread 2qdxy4rzwzuuilue
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 *intentionally*

Re: [Python-ideas] Why is design-by-contracts not widely

2018-09-28 Thread Steven D'Aprano
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

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Marko Ristin-Kaufmann
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 whole

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Paul Moore
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 ab

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread David Mertz
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 b

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread David Mertz
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 >> https://github.com/mristin/icont

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-28 Thread Anders Hovmöller
>>> 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 >> always interpreted as a method of the LHS. > > > You obviously have a diff

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Paul Moore
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 opera

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Chris Angelico
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 exc

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Jonathan Fine
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 exception

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Chris Angelico
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 jus

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-28 Thread Chris Angelico
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

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-28 Thread Jonathan Fine
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 >>>

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

2018-09-28 Thread Paul Moore
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 unpac

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-28 Thread Steven D'Aprano
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

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-28 Thread Jasper Rebane
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 ther

Re: [Python-ideas] Add .= as a method return value assignment operator

2018-09-28 Thread Brice Parent
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 user