On Fri, Sep 28, 2018 at 11:32 PM Steve Barnes wrote:
> 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
On 29/09/2018 07:52, Nathaniel Smith wrote:
> 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.
>
29.09.18 09:31, Steve Barnes пише:
I think that it should be relatively simple to extend the Python integer
class to have a NaN flag, possibly by having a bit length of 0, and have
it follow the same rules for the handling of floating point NaN, i.e.
any mathematical operation on an iNaN returns
On 29/09/2018 08:18, Michael Selik wrote:
> On Fri, Sep 28, 2018 at 11:32 PM Steve Barnes wrote:
>> 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
On 29/09/2018 08:24, Serhiy Storchaka wrote:
> 29.09.18 09:31, Steve Barnes пише:
>> I think that it should be relatively simple to extend the Python integer
>> class to have a NaN flag, possibly by having a bit length of 0, and have
>> it follow the same rules for the handling of floating point
29.09.18 10:35, Steve Barnes пише:
On 29/09/2018 08:24, Serhiy Storchaka wrote:
29.09.18 09:31, Steve Barnes пише:
I think that it should be relatively simple to extend the Python integer
class to have a NaN flag, possibly by having a bit length of 0, and have
it follow the same rules for the h
On Tue, Sep 25, 2018 at 08:01:28PM +1200, Robert Collins wrote:
> On Mon, 24 Sep 2018 at 19:47, Marko Ristin-Kaufmann
> wrote:
[...]
> > There are 150K projects on pypi.org. Each one of them would
> > benefit if annotated with the contracts.
>
> You'll lose folks attention very quickly when you
On 29/09/2018 08:50, Serhiy Storchaka wrote:
> 29.09.18 10:35, Steve Barnes пише:
>> On 29/09/2018 08:24, Serhiy Storchaka wrote:
>>> 29.09.18 09:31, Steve Barnes пише:
I think that it should be relatively simple to extend the Python
integer
class to have a NaN flag, possibly by h
29.09.18 11:43, Steve Barnes пише:
On 29/09/2018 08:50, Serhiy Storchaka wrote:
Python is dynamically typed language. What is such processing that would
work with iNaN, but doesn't work with float('nan')?
One simplistic example would be print(int(float('nan'))) (gives a
ValueError) while print
On Wed, Sep 26, 2018 at 05:40:45AM +1000, Chris Angelico wrote:
> > There are 150K projects on pypi.org. Each one of them would benefit
> > if annotated with the contracts.
>
> This is the extraordinary claim. To justify it, you have to show that
> virtually ANY project would benefit from contra
On Fri, 28 Sep 2018 23:52:22 -0700
Nathaniel Smith wrote:
> 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
On Wed, Sep 26, 2018 at 04:03:16PM +0100, Rhodri James wrote:
> Let's assume that the contracts are meaningful and useful (which I'm
> pretty sure won't be 100% true; some people are bound to assume that
> writing contracts means they don't have to think).
Contracts are a tool. We shouldn't ref
On Sat, Sep 29, 2018 at 10:32:16AM +1000, Chris Angelico wrote:
> What should happen here?
>
> >>> import ctypes
> >>> ctypes.cast(id(1), ctypes.POINTER(ctypes.c_int))[6] = 0
> >>> 1
>
> Nothing here invokes C's undefined behaviour. Or what about here:
>
> >>> import sys; sys.setrecursionlimit(
On Sat, Sep 29, 2018 at 2:32 AM Steve Barnes wrote:
> 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
On Sat, Sep 29, 2018 at 9:43 PM Steven D'Aprano wrote:
>
> On Sat, Sep 29, 2018 at 10:32:16AM +1000, Chris Angelico wrote:
>
> > What should happen here?
> >
> > >>> import ctypes
> > >>> ctypes.cast(id(1), ctypes.POINTER(ctypes.c_int))[6] = 0
> > >>> 1
> >
> > Nothing here invokes C's undefined b
On Sat, Sep 29, 2018 at 10:50:24AM +0300, Serhiy Storchaka wrote:
> >>How does it differ from float('nan')?
> >>
> >It is still an integer and would pass through any processing that
> >expected an integer as one, (with a value of iNaN).
>
> Python is dynamically typed language. What is such proce
29.09.18 15:19, Steven D'Aprano пише:
On Sat, Sep 29, 2018 at 10:50:24AM +0300, Serhiy Storchaka wrote:
How does it differ from float('nan')?
It is still an integer and would pass through any processing that
expected an integer as one, (with a value of iNaN).
Python is dynamically typed lang
On Sat, Sep 29, 2018 at 06:31:46AM +, Steve Barnes wrote:
> One of the strengths of the IEEE float, (to set against its many
> weaknesses),
o_O
Since I'm old enough to (just barely) remember the chaos and horror of
numeric programming before IEEE-754, I find that comment rather
shocking.
On 9/29/18 2:31 AM, Steve Barnes wrote:
> 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 c
On Sat, Sep 29, 2018 at 09:11:41AM -0400, Richard Damon wrote:
> I would think that a possibly better solution would be the creation of a
> NAN type (similar to NONE) that implement this sort of property. That
> way the feature can be added to integers, rationals, and any other
> numeric types th
On Sat, Sep 29, 2018 at 10:15:42PM +1000, Chris Angelico wrote:
[...]
> As are all the things that are "undefined behaviour" in C, like the
> result of integer overflow in a signed variable. They are "Here be
> dragons" territory, but somehow that's not okay for you. I don't
> understand why you c
Marko Ristin-Kaufmann writes:
> I annotated pathlib with contracts:
> https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML docs
Thank your for completing this task so quickly.
I'm sorry, but I didn't find it convincing. I'll leave others to
discuss the docs, as they are clearly
Steven D'Aprano writes:
> I just wish we didn't have to fight so hard to justify the very
> idea of contracts themselves.
You don't. You need to justify putting them in the stdlib. That's a
pretty high bar. And as crappy as the contracts in Marko's pathlib
rewrite look to me, I suspect you'l
Steven D'Aprano writes:
> put (x: ELEMENT; key: STRING) is
> -- Insert x so that it will be retrievable through key.
> require
> count <= capacity
> not key.empty
> do
> ... Some insertion algorithm ...
> ensure
>
Hi James,
What about a tool that we discussed, to convert contracts back and forth to
readable form on IDe save/load with the following syntax:
def some_func(arg1:int, arg2:int)-> int:
# typing on the phone so no indent
With requiring:
Assert arg1 < arg2, "some message"
With snapshotting:
On 29/09/2018 14:00, Steven D'Aprano wrote:
> On Sat, Sep 29, 2018 at 06:31:46AM +, Steve Barnes wrote:
>
>> One of the strengths of the IEEE float, (to set against its many
>> weaknesses),
>
> o_O
>
> Since I'm old enough to (just barely) remember the chaos and horror of
> numeric progra
On 29/09/2018 09:56, Serhiy Storchaka wrote:
> 29.09.18 11:43, Steve Barnes пише:
>> On 29/09/2018 08:50, Serhiy Storchaka wrote:
>>> Python is dynamically typed language. What is such processing that would
>>> work with iNaN, but doesn't work with float('nan')?
>>>
>> One simplistic example woul
Hi James,
Just a PS to the previous syntax:
with contracts:
with preconditions:
assert arg1 < arg2
with snapshot as S:
S.var1 = some_func(arg1)
with postconditions, \
result:
# result would be annotated with "# type:" if return type
is
29.09.18 21:38, Steve Barnes пише:
On 29/09/2018 09:56, Serhiy Storchaka wrote:
29.09.18 11:43, Steve Barnes пише:
On 29/09/2018 08:50, Serhiy Storchaka wrote:
Python is dynamically typed language. What is such processing that would
work with iNaN, but doesn't work with float('nan')?
One sim
P.p.s. to raise a custom exception:
if not (arg1 < S.var1 < arg2):
"Some description"
raise SomeException(arg1, S.var1, arg2)
The converter enforces that only "if not" statement is allowed, only a
string description (optional) followed by a raise in the body of
if-statement.
This is late
Hi James,
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 and compile a lambda function to be executed at actua
On Sun, Sep 30, 2018 at 12:43 AM Steven D'Aprano wrote:
>
> On Sat, Sep 29, 2018 at 10:15:42PM +1000, Chris Angelico wrote:
>
> [...]
> > As are all the things that are "undefined behaviour" in C, like the
> > result of integer overflow in a signed variable. They are "Here be
> > dragons" territor
On Sat, 29 Sep 2018 at 19:38, Steve Barnes wrote:
>
> On 29/09/2018 09:56, Serhiy Storchaka wrote:
> > 29.09.18 11:43, Steve Barnes пише:
> >> On 29/09/2018 08:50, Serhiy Storchaka wrote:
> >>> Python is dynamically typed language. What is such processing that would
> >>> work with iNaN, but doesn
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 process where a value is converted to a
> > whole number down in the d
On Sat, Sep 29, 2018 at 10:05:39PM +0300, Serhiy Storchaka wrote:
> 29.09.18 21:38, Steve Barnes пише:
[...]
> >>Why do you convert to int when you need a string representation? Just
> >>print(float('nan')).
> >>
> >>I converted to int because I needed a whole number, this was intended to
> >repre
Something to consider in all of this is that Python floats
often *don't* produce NaNs for undefined operations, but
raise exceptions instead:
>>> 1.0/0.0
Traceback (most recent call last):
File "", line 1, in
ZeroDivisionError: float division by zero
>>> math.sqrt(-1.0)
Traceback (most recent
On Sat, Sep 29, 2018 at 09:50:27AM +1000, Hugh Fisher wrote:
> Oh FFS. You couldn't make the effort to read the very next sentence,
> let alone the next paragraph, before responding?
Hugh, your mind-reading powers are fading. I read not just the next
sentence and paragraph but the entire post. Th
On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano wrote:
> This discussion is for those of us who would like to include DbC in our
> projects but don't like existing solutions. C++ being designed with a
> shovel is not relevant.
>
> (Except in the sense that we should always be careful about piling
On Sun, Sep 30, 2018 at 12:17:25PM +1000, Chris Angelico wrote:
> On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano wrote:
> > This discussion is for those of us who would like to include DbC in our
> > projects but don't like existing solutions. C++ being designed with a
> > shovel is not relevant
On 30Sep2018 12:17, Chris Angelico wrote:
At the moment, I'm seeing decorator-based contracts as a clunky
version of unit tests. We already have "inline unit testing" - it's
called doctest - and I haven't seen anything pinned down as "hey, this
is what it'd take to make contracts more viable". C
On Sun, Sep 30, 2018 at 2:27 PM Steven D'Aprano wrote:
>
> On Sun, Sep 30, 2018 at 12:17:25PM +1000, Chris Angelico wrote:
> > On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano
> > wrote:
> > > This discussion is for those of us who would like to include DbC in our
> > > projects but don't like e
Hi James,
I copy/pasted the discussion re the readability tool to an issue on github:
https://github.com/Parquery/icontract/issues/48
Would you mind opening a separate issue and copy/pasting what you find
relevant re MockP approach in a separate issue?
I think it's time to fork the issues and ha
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:
>>> None
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,
Marko
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
45 matches
Mail list logo
