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
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 or doesn't fit into python's duck-typing
philosophy.
I find that when I detect inv
11 matches
Mail list logo
