On Thursday, September 21, 2017 at 9:29:19 AM UTC-7, Tobiah wrote:
> Are these completely equivalent?
>
> def foo(thing):
>
> assert(thing > 0), "Thing must be greater than zero"
>
>
> def foo(thing):
>
> if not (thing > 0): raise AssertionError("Thing must be greater than
> z
Op 2017-09-22, Thomas Jollans schreef :
> Just to make the implication explicit:
>
from math import nan
nan is nan
> True
nan == nan
> False
nan != nan
> True
To add to the fun:
>>> nan is nan
True
Stephan
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-09-22 14:43, Steve D'Aprano wrote:
> In the case of floating point NANs, they are unordered with respect to all
> numbers. So for any number x, we always have:
>
> NAN == x
> NAN < x
> NAN > x
> NAN <= x
> NAN >= x
>
> all return False, and
>
> NAN != x
>
> return True.
Just to make t
On Fri, 22 Sep 2017 10:03 pm, alister wrote:
> On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote:
>
>> On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>>
The bottom line is, if I saw
if not (thing > 0): raise AssertionError(...)
in a code review, I'd probably insis
On 2017-09-22 14:03, alister via Python-list wrote:
> On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote:
>> On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>>> [snip]
>>>
>>> In a code review I would want the condition changed to be less noisy/
>>> confusing to the reader.
>>>
>>> if thing <=0:
On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote:
> On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>
>>> The bottom line is, if I saw
>>>
>>> if not (thing > 0): raise AssertionError(...)
>>>
>>> in a code review, I'd probably insist that either it be changed to use
>>> `assert`,
>>> or t
On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>> The bottom line is, if I saw
>>
>> if not (thing > 0): raise AssertionError(...)
>>
>> in a code review, I'd probably insist that either it be changed to use
>> `assert`,
>> or the exception be changed to ValueError, whichever better expresses
>> t
On Fri, 22 Sep 2017 03:44:59 +1000, Steve D'Aprano wrote:
> On Fri, 22 Sep 2017 02:29 am, Tobiah wrote:
>
>> Are these completely equivalent?
>>
>> def foo(thing):
>>
>> assert(thing > 0), "Thing must be greater than zero"
>>
>>
>> def foo(thing):
>>
>> if not (thing > 0): ra
On Fri, Sep 22, 2017 at 3:49 AM, Steve D'Aprano
wrote:
> On Fri, 22 Sep 2017 03:31 am, Chris Angelico wrote:
>
>> Impressive. That means that, in 2.7, it's actually equivalent to:
>>
> def test3():
>> ... if not foo: raise AssertionError, "bar baz"
>
> That's nothing. In 1.5 (yes, *one* po
On Fri, 22 Sep 2017 03:31 am, Chris Angelico wrote:
> On Fri, Sep 22, 2017 at 3:23 AM, Steve D'Aprano
> wrote:
>> That is definitely version-dependent, because I've just tried it and got
>> different byte-code in Python 2.7.
>>
>> py> import dis
>> py> def test1():
>> ... assert foo, "bar baz
On Fri, 22 Sep 2017 02:29 am, Tobiah wrote:
> Are these completely equivalent?
>
> def foo(thing):
>
> assert(thing > 0), "Thing must be greater than zero"
>
>
> def foo(thing):
>
> if not (thing > 0): raise AssertionError("Thing must be greater than
> zero")
>
>
> O
On Fri, Sep 22, 2017 at 3:23 AM, Steve D'Aprano
wrote:
> That is definitely version-dependent, because I've just tried it and got
> different byte-code in Python 2.7.
>
> py> import dis
> py> def test1():
> ... assert foo, "bar baz"
> ...
> py> def test2():
> ... if not foo: raise Assertio
On Fri, 22 Sep 2017 02:59 am, Ned Batchelder wrote:
> On 9/21/17 12:29 PM, Tobiah wrote:
>> Are these completely equivalent?
[... assert, versus test and raise AssertionError ...]
> Let's see:
[...]
> Yes, they are completely equivalent, compiling to precisely the same
> bytecode.
That is defin
On 9/21/17 12:29 PM, Tobiah wrote:
Are these completely equivalent?
def foo(thing):
assert(thing > 0), "Thing must be greater than zero"
def foo(thing):
if not (thing > 0): raise AssertionError("Thing must be greater than
zero")
Other than the fact that the assertion can
On Fri, 07 Mar 2014 16:15:36 -0800, Dan Stromberg wrote:
> On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano
> wrote:
>
>
>> Assertions are not bad! They're just misunderstood and abused.
>
>> You should read this guy's blog post on when to use assert:
>>
>> http://import-that.dreamwidth.org/676
On 8-3-2014 1:15, Dan Stromberg wrote:
> On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano
> wrote:
>
>>
>> Assertions are not bad! They're just misunderstood and abused.
>
>> You should read this guy's blog post on when to use assert:
>>
>> http://import-that.dreamwidth.org/676.html
>
> Nice art
Dan Stromberg writes:
> BTW, what about:
>
> if value >= 3:
>raise AssertionError('value must be >= 3')
That would be very confusing, since it would only appear when the value
is >= 3. Were you making some other point?
--
\“If this is your first visit to the USSR, you are welcome
On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano
wrote:
>
> Assertions are not bad! They're just misunderstood and abused.
> You should read this guy's blog post on when to use assert:
>
> http://import-that.dreamwidth.org/676.html
Nice article.
BTW, what about:
if value >= 3:
raise Asserti
On Fri, Mar 7, 2014 at 10:11 PM, Steven D'Aprano
wrote:
>> http://xkcd.com/1339/
>>
>> Abusing assert for arg checking violates XKCD 1339. Write
>> standards-compliant code!
>
> Assertions are not bad! They're just misunderstood and abused.
>
> (By the way, assertions are not the same as assumptio
On Fri, 07 Mar 2014 18:16:55 +1100, Chris Angelico wrote:
> They produce the wrong exception type, they disappear when you least
> expect them, and now we have another reason not to use assert.
>
> http://xkcd.com/1339/
>
> Abusing assert for arg checking violates XKCD 1339. Write
> standards-co
alex23 wrote:
> r0g wrote:
>> Well I think sometimes, for the sake of expediency and overall
>> pleasantness, it's better to let the smaller things go: and if you just
>> can't let them go then at least try and issue corrections in a friendly
>> manner rather than a cold or pious one.
>
> The iro
r0g wrote:
> Well I think sometimes, for the sake of expediency and overall
> pleasantness, it's better to let the smaller things go: and if you just
> can't let them go then at least try and issue corrections in a friendly
> manner rather than a cold or pious one.
The irony, it is too rich...
--
Ben Finney wrote:
> r0g writes:
>
>> Ben Finney wrote:
>>> People sometimes get upset — on an immediate, irrational level —
>>> when their assertions are challenged. There's no denying that
>>> emotions entangle our discourse, and our interpretation of the
>>> discourse of others.
>> That's truer
r0g writes:
> Ben Finney wrote:
> > People sometimes get upset — on an immediate, irrational level —
> > when their assertions are challenged. There's no denying that
> > emotions entangle our discourse, and our interpretation of the
> > discourse of others.
>
> That's truer than most people appr
Ben Finney wrote:
> In fairness, the “No” was in response, not to an explicit question, but
> to an assertion.
>
> Every assertion expressed, though, implies the question “is this
> assertion true?”. It was that question that was answered “No” (followed
> by an explanation of why the assertion was
On Sat, 27 Jan 2007 19:29:06 -0800, Carl Banks wrote:
> On Jan 27, 6:51 pm, Steven D'Aprano
> <[EMAIL PROTECTED]> wrote:
>> On Sat, 27 Jan 2007 06:58:04 -0800, Carl Banks wrote:
>> >> I find that when I detect invalid parameters overtly, I spend less time
>> >> debugging.
>>
>> > If it helps go a
On Jan 27, 6:51 pm, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Sat, 27 Jan 2007 06:58:04 -0800, Carl Banks wrote:
> >> I find that when I detect invalid parameters overtly, I spend less time
> >> debugging.
>
> > If it helps go ahead an use them. The world won't end if you use an
> > asser
On Sat, 27 Jan 2007 06:58:04 -0800, Carl Banks wrote:
>> I find that when I detect invalid parameters overtly, I spend less time
>> debugging.
>
> If it helps go ahead an use them. The world won't end if you use an
> assertion in a less than ideal situation. And, after all, if someone
> doesn
On Jan 25, 11:54 am, Matthew Wilson <[EMAIL PROTECTED]> wrote:
> Lately, I've been writing functions like this:
>
> def f(a, b):
>
> assert a in [1, 2, 3]
> assert b in [4, 5, 6]
>
> The point is that I'm checking the type and the values of the
> parameters.
>
> I'm curious how this does
On Jan 25, 11:26 pm, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> Note also that for real code, a bare assert like that is uselessly
> uninformative:
>
> >>> x = 1
> >>> assert x == 3Traceback (most recent call last):
> File "", line 1, in ?
> AssertionError
In real code, a traceback usually
Matthew Woodcraft <[EMAIL PROTECTED]> wrote:
> I have a question for you. Consider this function:
>
> def f(n):
> """Return the largest natural power of 2 which does not exceed n."""
> if n < 1:
> raise ValueError
> i = 1
> while i <= n:
> j = i
> i
On Fri, 26 Jan 2007 18:28:32 +, Matthew Woodcraft wrote:
> I have a question for you. Consider this function:
>
> def f(n):
> """Return the largest natural power of 2 which does not exceed n."""
> if n < 1:
> raise ValueError
> i = 1
> while i <= n:
> j = i
>
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> The less your function does, the more constrained it is, the less
> testing you have to do -- but the less useful it is, and the more work
> you put onto the users of your function. Instead of saying something
> like
> a = MyNumericClass(1)
> b = MyNum
On Thu, 25 Jan 2007 16:54:05 +, Matthew Wilson wrote:
> Lately, I've been writing functions like this:
>
> def f(a, b):
>
> assert a in [1, 2, 3]
> assert b in [4, 5, 6]
>
> The point is that I'm checking the type and the values of the
> parameters.
If somebody passes in a == MyNum
On Jan 25, 11:54 am, Matthew Wilson <[EMAIL PROTECTED]> wrote:
> Lately, I've been writing functions like this:
>
> def f(a, b):
>
> assert a in [1, 2, 3]
> assert b in [4, 5, 6]
>
> The point is that I'm checking the type and the values of the
> parameters.
>
> I'm curious how this does o
35 matches
Mail list logo
