On Thu, Aug 30, 2018 at 4:30 PM, Jonathan Goble wrote:
> On Thu, Aug 30, 2018, 2:08 AM Greg Ewing
> wrote:
>>
>> Also, Fraction(1) for the second case would be flat-out wrong.
>
>
> How? Raising something to the 2/3 power means squaring it and then taking
> the cube root of it. -1 squared is 1, a
On Thu, Aug 30, 2018 at 2:09 AM Greg Ewing
wrote:
> Jeroen Demeyer wrote:
> > On 2018-08-30 06:39, Neil Girdhar wrote:
> >
> >> I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
> >
> > Why? I cannot think of any natural use case why you would want Fractions
> > for a few special ca
On Thu, Aug 30, 2018, 2:08 AM Greg Ewing
wrote:
> Also, Fraction(1) for the second case would be flat-out wrong.
>
How? Raising something to the 2/3 power means squaring it and then taking
the cube root of it. -1 squared is 1, and the cube root of 1 is 1. Or am I
having a 2:30am brain fart?
>
_
Jeroen Demeyer wrote:
On 2018-08-30 06:39, Neil Girdhar wrote:
I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
Why? I cannot think of any natural use case why you would want Fractions
for a few special cases on an operation which returns non-Fractions
generically.
Also, Fr
On 2018-08-30 06:39, Neil Girdhar wrote:
I'd like these to be Fraction(1), Fraction(1), and Fraction(0).
Why? I cannot think of any natural use case why you would want Fractions
for a few special cases on an operation which returns non-Fractions
generically.
I consider it a feature to know
Would there be any problem with changing:
In [4]: Fraction(1, 1) ** Fraction(2, 3)
Out[4]: 1.0
In [5]: Fraction(-1, 1) ** Fraction(2, 3)
Out[5]: (-0.4998+0.8660254037844387j)
In [6]: Fraction(0, 1) ** Fraction(2, 3)
Out[6]: 0.0
I'd like these to be Fraction(1), Fraction(1), and Frac
On 08/29/2018 04:53 PM, Hugh Fisher wrote:
From: Marko Ristin-Kaufmann:
There seems to be evidence that design-by-contract is useful. Let me cite
Bertrand Meyer from his article "Why not program right?" that I already
mentioned before:
I don't think that being useful by itself should be enou
Dear all,
I would like to use zipfile encryption as python standard library.
https://github.com/python/cpython/blob/master/Lib/zipfile.py
Below document says "currently" cannot.
https://github.com/python/cpython/blob/master/Doc/library/zipfile.rst
"but it currently cannot create an encrypted file
> Date: Thu, 30 Aug 2018 00:07:04 +0200
> From: Marko Ristin-Kaufmann
...
> I think we got entangled in a discussion about whether design-by-contract
> is useful or not. IMO, the personal experience ("I never used/needed this
> feature") is quite an inappropriate rule whether something needs to be
On 8/29/2018 6:39 PM, Eric Fahlgren wrote:
On Wed, Aug 29, 2018 at 3:07 PM Marko Ristin-Kaufmann
mailto:marko.ris...@gmail.com>> wrote:
Could you please elaborate a bit? I don't see how the annotations
would make the contracts invoked on inheritance. Consider this
simple case:
replying to the list now...
On Thu, 30 Aug 2018 at 00:11, Ivan Levkivskyi wrote:
> On Wed, 29 Aug 2018 at 13:18, Steven D'Aprano wrote:
>
>> I didn't want to embarass Ivan any further by seemingly picking on his
>> opinion about contracts being always statically checked, but when I
>> asked off
The technique Eric suggests is probably better than what I had in mind.
But I was thinking you could have an "inherit" decorator for methods (or
for a class as a whole). It's easy enough for a decorator to attach a
`.__contracts__` attribute to either the class or the individual methods.
Then the
On Wed, Aug 29, 2018 at 3:07 PM Marko Ristin-Kaufmann <
marko.ris...@gmail.com> wrote:
> Could you please elaborate a bit? I don't see how the annotations would
> make the contracts invoked on inheritance. Consider this simple case:
>
> class A:
> @icontract.pre(lambda x: x > 0)
> def some
Hi,
I think we got entangled in a discussion about whether design-by-contract
is useful or not. IMO, the personal experience ("I never used/needed this
feature") is quite an inappropriate rule whether something needs to be
introduced into the language or not.
There seems to be evidence that design
Jonathan Fine wrote:
My message of support for Ivan quoted the Eiffel docs.
https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions
During development and testing, assertion monitoring should
be turned on at the highest possible level. Combined with
st
On Wed, Aug 29, 2018 at 02:26:54PM +0100, Jonathan Fine wrote:
> This is about a difference of opinion regarding design by contract and
> static checking, that Steve D'Aprano has re-raised. Steve wrote that
> Ivan Levkivskyi's opinion was that:
>
> > contracts [are] always statically checked
>
>
This is about a difference of opinion regarding design by contract and
static checking, that Steve D'Aprano has re-raised. Steve wrote that
Ivan Levkivskyi's opinion was that:
> contracts [are] always statically checked
This is what Ivan wrote:
> TBH, I think one of the main points of design by
On Wed, 29 Aug 2018 at 13:26, Steven D'Aprano wrote:
>
> [steve@ando ~]$ pip install numpy
> Collecting numpy
> /usr/local/lib/python3.5/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:315:
> SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject
> Name Indication
On Wed, 29 Aug 2018 at 13:17, Oscar Benjamin wrote:
> Scipy (on Windows) is a different story.
There are Windows (and other platform) wheels for scipy 1.1.0 on PyPI,
so that's easy too :-)
Paul
___
Python-ideas mailing list
Python-ideas@python.org
htt
On Wed, Aug 29, 2018 at 01:15:46PM +0100, Oscar Benjamin wrote:
> On Tue, 28 Aug 2018 at 08:12, Jacco van Dorp wrote:
> >
> > Op ma 27 aug. 2018 om 23:18 schreef James Lu :
> >>
> >> > As Matthew points out, you could use numpy.array. Or code your own
> >> > class, by providing __add__ and __iadd_
I didn't want to embarass Ivan any further by seemingly picking on his
opinion about contracts being always statically checked, but when I
asked off-list I got told to reword and post it here. So here it is.
Sorry Ivan if this makes you feel I'm picking on you, that isn't my
intention.
On Mon
On Tue, 28 Aug 2018 at 08:12, Jacco van Dorp wrote:
>
> Op ma 27 aug. 2018 om 23:18 schreef James Lu :
>>
>> > As Matthew points out, you could use numpy.array. Or code your own
>> > class, by providing __add__ and __iadd__ methods.
>>
>> I could, but I don't think that justifies not having this f
On Wed, Aug 29, 2018 at 09:23:02AM +0200, Jacco van Dorp wrote:
> Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano :
>
> > On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote:
> > > Hi,
> > > To clarify the benefits of the contracts, let me give you an example from
> > > our c
On Wed, Aug 29, 2018 at 05:52:46PM +1200, Greg Ewing wrote:
> Wes Turner wrote:
> >I'm going to re-write that in a pseudo-Eiffel like syntax:
>
> Maybe some magic could be done to make this work:
>
> def __init__(self, img: np.ndarray, x: int, y: int, width: int,
> height: i
Op wo 29 aug. 2018 om 03:59 schreef Steven D'Aprano :
> On Tue, Aug 28, 2018 at 07:46:02AM +0200, Marko Ristin-Kaufmann wrote:
> > Hi,
> > To clarify the benefits of the contracts, let me give you an example from
> > our code base:
> >
> > @icontract.pre(lambda x: x >= 0)
> > @icontract.pre(lambda
I've never used contracts, so excuse me if I didn't get how they would
work, and what they should do.
The last example is about pre-post conditions in a class constructor.
But I imagine this is not the only case where one would want to define
contracts, like probably: within methods that retur
26 matches
Mail list logo
