Re: [Python-ideas] Upgrade to Mailman 3

re: message URL in mm3 footers (after sig dashes: '\n--\n') "This list will soon be migrating to Mailman 3" https://mail.python.org/mm3/archives/list/distutils-...@python.org/thread/IHWUGVND3FU2UH3GEC2GYOSOJJMKLO5H/ On Sunday, September 30, 2018, James Lu wrote: > It has a nice GUI for people

[Python-ideas] Renaming icontract to pcontract

Hi, I'd like to rename icontract into pcontract to avoid name conflict with java's icontract library. Do you have any better suggestion? Thanks! Marko ___ Python-ideas mailing list Python-ideas@python.org

[Python-ideas] Transpiling contracts

Hi James, Regarding the “transpile into Python” syntax with with statements: Can I > see an example of this syntax when used in pathlib? I’m a bit worried this > syntax is too long and “in the way”, unlike decorators which are before the > function body. Or do you mean that both MockP and your

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

Hi James, I agree. Having a snapshot decorator per variable also has the advantage that we can add parameters to the decorator (e.g., snapshots also need "enabled" and "description" argument). How should we distinguish the two approaches? (I suppose you would also apply them to requests, ensures

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

Hi James, Sure, let's do that! I'm fine with emails, too. I needed only a bit of structure since we lumped so many issues together, but maybe it's just my OCD :) Le lun. 1 oct. 2018 à 04:05, James Lu a écrit : > Hi Marko, > > Regarding switching over to GitHub issues: > * I copy-pasted the

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

Hi Marko, Regarding switching over to GitHub issues: * I copy-pasted the MockP original code to GitHub issues. * There's a clunky way to view the discussion at https://mail.python.org/pipermail/python-ideas/2018-September/subject.html#start . * The less clunky way to view the discussion is to

[Python-ideas] Upgrade to Mailman 3

It has a nice GUI for people who spectate a discussion to read emails without having to subscribe to the list. http://docs.mailman3.org/en/latest/migration.html ___ Python-ideas mailing list Python-ideas@python.org

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

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 Barnes wrote: > > > > > > > I converted to int because I needed a whole

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

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 Barnes wrote: > > > > > I converted to int because I needed a whole number, this was intended to > > > represent some more complex

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

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 implementation. Can you show an example of code written in a language with support for

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

As others have said, I do not think directly changing int is a good idea. It would break so much existing code if an unexpected iNaN appeared. I also think having a nan-aware subclass should be the other way around. If you are expecting a nan-aware int, a regular int would work fine. If you are

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

Hi James, (I'm just about to go to sleep, so I'll answer the other messages tomorrow.) Should we keep some kind of document to keep track of all the different > proposals? I’m thinking an editable document like HackMD where we can label > all the different ideas to keep them straight in our head.

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

Hi Marko, I just found the time to reply to these. > I reread the proposal with MockP. I still don't get the details, but if I > think I understand the basic idea. You put a placeholder and whenever one of > its methods is called (including dunders), you record it and finally assemble > an AST

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

Hi Marko, Regarding the “transpile into Python” syntax with with statements: Can I see an example of this syntax when used in pathlib? I’m a bit worried this syntax is too long and “in the way”, unlike decorators which are before the function body. Or do you mean that both MockP and your

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

Hi Marko, > If the documentation is clear, I'd expect the user to be able to distinguish > the two. The first approach is shorter, and uses magic, but fails in some > rare situations. The other method is more verbose, but always works. I like this idea. James Lu > On Sep 29, 2018, at 1:36 AM,

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

Hi Marko, Going back to your proposal on repeating lambda P as a convention. I do find @snapshot(some_identifier=P -> P.self(P.arg1), some_identifier2=P -> P.arg1 + P.arg2) acceptable. Should we keep some kind of document to keep track of all the different proposals? I’m thinking an

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

On 30/09/2018 16:36, David Mertz wrote: > On Sun, Sep 30, 2018 at 11:31 AM Steve Barnes > wrote: > > No complex can be converted to float without accessing either the real > or imag component. > > > Sure. Not in Python 3.7.  But mathematically, it seems

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

On Sun, Sep 30, 2018 at 11:35 AM Chris Angelico wrote: > On Mon, Oct 1, 2018 at 1:32 AM Steve Barnes > wrote: > > No complex can be converted to float without accessing either the real > > or imag component. > Or taking its absolute value, which will return nan if either part is nan. > Well,

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

On Sun, Sep 30, 2018 at 11:31 AM Steve Barnes wrote: > No complex can be converted to float without accessing either the real > or imag component. > Sure. Not in Python 3.7. But mathematically, it seems really straightforward to say that Complex numbers that lie on the Real line (i.e.

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

On Mon, Oct 1, 2018 at 1:32 AM Steve Barnes wrote: > > No complex can be converted to float without accessing either the real > or imag component. > Or taking its absolute value, which will return nan if either part is nan. ChrisA ___ Python-ideas

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

On Sun, Sep 30, 2018 at 10:29:50AM -0400, David Mertz wrote: > I think Steven's is backwards in its own way. > >- Contracts test the space of arguments *actually used during testing >period* (or during initial production if the performance hit is >acceptable). >- Unit tests test

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

On 30/09/2018 16:26, David Mertz wrote: > On Sun, Sep 30, 2018 at 11:17 AM Steve Barnes > wrote: > > Note that my statements above had a single = i.e. > float(NaNAwareInt('nan')) produces float('nan'), etc., as does: > > In [42]: nan =

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

On Sun, Sep 30, 2018 at 11:17 AM Steve Barnes wrote: > Note that my statements above had a single = i.e. > float(NaNAwareInt('nan')) produces float('nan'), etc., as does: > > In [42]: nan = decimal.Decimal('nan') > In [43]: decimal.Decimal(nan) > Out[43]: Decimal('NaN') > In [44]: float(nan) >

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

On 30/09/2018 16:13, David Mertz wrote: > On Sun, Sep 30, 2018 at 11:01 AM Steve Barnes > wrote: > > Adding inf & -inf would be nice but to do so we would need a better > name > than NaNAwareInt. > > > My placeholder name is deliberately awkward.  I

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

On Sun, Sep 30, 2018 at 11:01 AM Steve Barnes wrote: > Adding inf & -inf would be nice but to do so we would need a better name > than NaNAwareInt. > My placeholder name is deliberately awkward. I think it gestures at the concept for discussion purposes though. > It would also be nice if

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

On Sun, Sep 30, 2018 at 11:04 AM Chris Angelico wrote: > On Mon, Oct 1, 2018 at 12:58 AM David Mertz wrote: > >> I'm not sure what's going on. I have a Py3 busily calculating > >> 2**(2**65) and it's pegging a CPU core while progressively consuming > >> memory, but it responds to Ctrl-C, which

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

On Mon, Oct 1, 2018 at 12:58 AM David Mertz wrote: >> I'm not sure what's going on. I have a Py3 busily calculating >> 2**(2**65) and it's pegging a CPU core while progressively consuming >> memory, but it responds to Ctrl-C, which suggests that Python bytecode >> is still being executed. > > >

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

On 30/09/2018 15:15, David Mertz wrote: > For similar reasons, I'd like an iInf too, FWIW.  It's good for an > overflow value, although it's hard to get there in Python ints (would > 'NaNAwareInt(1)/0' be an exception or iInf?).  Bonus points for anyone > who knows the actual maximum size of

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

On Sun, Sep 30, 2018 at 10:49 AM Chris Angelico wrote: > > int.bit_length() is stored as a system-native integer, e.g. 64-bit, > rather than recursively as a Python int. So the largest Python int is > '2**sys.maxsize` (e.g. '2**(2**63-1)'). I may possibly have an off-by-one > or

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

On Sun, Sep 30, 2018 at 09:55:58AM -0400, David Mertz wrote: > Notwithstanding my observation of one case where 'nan float' doesn't > stay a nan, I definitely want something like iNaN. Btw are there other > operations on NaN's do not produce NaN's? Yes. The (informal?) rule applied by IEEE-754

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

On Mon, Oct 1, 2018 at 12:45 AM Anders Hovmöller wrote: > But making any change to the basic types truth table is a big -1 from me. > This seems like a Python 2-3 transition to me. > Far FAR worse than anything that changed in Py2->Py3. ChrisA ___

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

On Mon, Oct 1, 2018 at 12:44 AM David Mertz wrote: > > On Sun, Sep 30, 2018 at 10:23 AM Chris Angelico wrote: >> >> On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote: >> > Bonus points for anyone who knows the actual maximum size of Python ints >> > :-). >> >> Whatever the maximum is, it's

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

>> 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. (anything op iNaN) = iNaN and likewise for shift >>

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

On Sun, Sep 30, 2018 at 10:23 AM Chris Angelico wrote: > On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote: > > Bonus points for anyone who knows the actual maximum size of Python ints > :-). > > Whatever the maximum is, it's insanely huge. > Want to share what the maximum actually is? I'm very

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

On 2018-09-30 10:15, David Mertz wrote: > For similar reasons, I'd like an iInf too, FWIW.  It's good for an > overflow value, although it's hard to get there in Python ints (would > 'NaNAwareInt(1)/0' be an exception or iInf?).  Bonus points for anyone > who knows the actual maximum size of

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

On Sat, Sep 29, 2018 at 7:20 AM Steven D'Aprano wrote: > On Wed, Sep 26, 2018 at 04:03:16PM +0100, Rhodri James wrote: > > Assuming that you > > aren't doing some kind of wide-ranging static analysis (which doesn't > > seem to be what we're talking about), all that the contracts have bought > >

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

On Fri, Sep 28, 2018 at 01:49:01PM +0100, Paul Moore wrote: > There's clearly a number of trade-offs going on here: > > * Conditions should be short, to avoid clutter > * Writing helper functions that are *only* used in conditions is more > code to test or get wrong This is no different from

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

On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote: > > For similar reasons, I'd like an iInf too, FWIW. It's good for an overflow > value, although it's hard to get there in Python ints (would > 'NaNAwareInt(1)/0' be an exception or iInf?). Bonus points for anyone who > knows the actual

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

On 2018-09-30 09:41, Steve Barnes 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. (anything op iNaN) =

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

On 2018-09-30 09:41, Steve Barnes 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. (anything op iNaN) =

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

For similar reasons, I'd like an iInf too, FWIW. It's good for an overflow value, although it's hard to get there in Python ints (would 'NaNAwareInt(1)/0' be an exception or iInf?). Bonus points for anyone who knows the actual maximum size of Python ints :-). However, the main use I'd have for

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

Notwithstanding my observation of one case where 'nan float' doesn't stay a nan, I definitely want something like iNaN. Btw are there other operations on NaN's do not produce NaN's? I suspect a NaNAwareInt subclass is the easiest way to get there, but I'm agnostic on that detail. For the very

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

On 30/09/2018 13:55, Steven D'Aprano wrote: > On Sun, Sep 30, 2018 at 12:09:45PM +0300, Serhiy Storchaka wrote: >> 30.09.18 04:07, Steven D'Aprano пише: >>> Telling people that they don't understand their own code when you don't >>> know their code is not very productive. >> >> I can't tell him

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

On Sun, Sep 30, 2018 at 12:09:45PM +0300, Serhiy Storchaka wrote: > 30.09.18 04:07, Steven D'Aprano пише: > >Telling people that they don't understand their own code when you don't > >know their code is not very productive. > > I can't tell him what he should do with his (not working) code, but

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

On Sun, Sep 30, 2018, 15:12 Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Steven D'Aprano writes: > > > (4) Inheritance > > > > Contracts are inherited, unit tests are not. > > What does "inherited" mean? Just that methods that are not overridden > retain their

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

Steven D'Aprano writes: > (1) Distance > (2) Self-documenting code > (3) The "Have you performed the *right* tests?" problem > (4) Inheritance > > Contracts are inherited, unit tests are not. What does "inherited" mean? Just that methods that are not overridden retain their

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

30.09.18 04:07, Steven D'Aprano пише: Telling people that they don't understand their own code when you don't know their code is not very productive. I can't tell him what he should do with his (not working) code, but it doesn't look like a good justification for changes in the Python core.

Re: [Python-ideas] Make None a subclass of int [alternative to iNaN]

30.09.18 09:05, Ken Hilton пише: Reading the iNaN discussion, most of the opposition seems to be that adding iNaN would add a new special value to integers and therefore add new complexity. I propose, instead, that we make None a subclass of int (or even a certain value of int) to represent

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

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 we get some examples that actually do a better job of > > selling contracts?

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

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 we get some examples that actually do a better job of > selling contracts? In no particular order... (1) Distance Unit tests are far away

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

Hi Cameron, Just a word of caution: I made a mistake and badly designed interface to icontract. It will change in the near future from: @post(lambda arg1, arg2, result: arg1 < result < arg2) most probably to: @ensures(lambda P: P.arg1 < result < P.arg2) This avoids any name conflicts with

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

Hi, I compiled a couple of issues on github to provide a more structured ground for discussions on icontract features: https://github.com/Parquery/icontract/issues (@David Maertz: I also included the issue with automatically generated __doc__ in case you are still interested in it). Cheers,

[Python-ideas] Make None a subclass of int [alternative to iNaN]

Hi all, Reading the iNaN discussion, most of the opposition seems to be that adding iNaN would add a new special value to integers and therefore add new complexity. I propose, instead, that we make None a subclass of int (or even a certain value of int) to represent iNaN. Therefore: >>>