Neil Cerutti wrote:
> On 2007-01-16, Ron Adam <[EMAIL PROTECTED]> wrote:
> > I have to admit that part of why assert seems wrong to me is
> > the meaning of the word implies something you shouldn't be able
> > to ignore. While warnings seem like something that can be
> > disregarded.
>
> Experien
Neil Cerutti wrote:
> On 2007-01-16, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I have to admit that part of why assert seems wrong to me is
>> the meaning of the word implies something you shouldn't be able
>> to ignore. While warnings seem like something that can be
>> disregarded.
>
> Experi
On 2007-01-16, Ron Adam <[EMAIL PROTECTED]> wrote:
> I have to admit that part of why assert seems wrong to me is
> the meaning of the word implies something you shouldn't be able
> to ignore. While warnings seem like something that can be
> disregarded.
Experienced C coders expect assert to beha
Carl Banks wrote:
> Ron Adam wrote:
>> There have been times where I would like assert to be a little more assertive
>> than it is. :-)
>>
>> ie.. not being able to turn them off with the -0/-00 switches, and having
>> them
>> generate a more verbose traceback.
>
> Personally, I'd rather see it
Ron Adam wrote:
> There have been times where I would like assert to be a little more assertive
> than it is. :-)
>
> ie.. not being able to turn them off with the -0/-00 switches, and having them
> generate a more verbose traceback.
Personally, I'd rather see it get less assertive, i.e., having
Steven D'Aprano wrote:
> On Mon, 15 Jan 2007 21:01:35 -0600, Ron Adam wrote:
>
>
>> There have been times where I would like assert to be a little more
>> assertive
>> than it is. :-)
>>
>> ie.. not being able to turn them off with the -0/-00 switches, and having
>> them
>> generate a more v
On Mon, 15 Jan 2007 21:01:35 -0600, Ron Adam wrote:
> There have been times where I would like assert to be a little more assertive
> than it is. :-)
>
> ie.. not being able to turn them off with the -0/-00 switches, and having
> them
> generate a more verbose traceback.
If you want somethi
On 1/15/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote:
>
> > assert foo(0x10) == 0 # Assertions are much better tests than prints :-)
>
> I dispute that assertion (pun intended).
Hah!
> Firstly, print statements work even if you pass t
On 1/15/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Jan 2007 21:38:42 -0500, Calvin Spealman wrote:
>
> > On 1/15/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> >> On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote:
> >>
> >> > assert foo(0x10) == 0 # Assertions are much b
On Mon, 15 Jan 2007 21:38:42 -0500, Calvin Spealman wrote:
> On 1/15/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote:
>>
>> > assert foo(0x10) == 0 # Assertions are much better tests than prints :-)
>>
>> I dispute that assertion (pun in
Calvin Spealman wrote:
> On 1/15/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote:
>>
>>> assert foo(0x10) == 0 # Assertions are much better tests than prints :-)
>> I dispute that assertion (pun intended).
>
> Hah!
>
>> Firstly, print s
On Mon, 15 Jan 2007 17:50:56 -0500, Calvin Spealman wrote:
> assert foo(0x10) == 0 # Assertions are much better tests than prints :-)
I dispute that assertion (pun intended).
Firstly, print statements work even if you pass the -O (optimize) flag
to Python. Your asserts don't.
Secondly, a bare
At Monday 15/1/2007 19:28, Jim B. Wilson wrote:
Am I nuts? Or only profoundly confused? I expected the this little script
to print "0":
class foo(int):
def __init__(self, value):
self = value & 0xF
print foo(0x10)
Instead, it prints "16" (at least on python 2.4.4 (Linux) and 2.5 (Wine).
Jim B. Wilson wrote:
> Am I nuts? Or only profoundly confused? I expected the this little script
> to print "0":
>
> class foo(int):
> def __init__(self, value):
> self = value & 0xF
That statement only rebinds the local name self to something else. It does not
modify the object at all or
As it turns out, this has little to do with integers and the
operations you are trying to do on them. I'll explain in more detail.
Integers are immutable, which you may already know. This presents a
problem with subclassing them and using the usual special method
__init__, because the int object h
Am I nuts? Or only profoundly confused? I expected the this little script
to print "0":
class foo(int):
def __init__(self, value):
self = value & 0xF
print foo(0x10)
Instead, it prints "16" (at least on python 2.4.4 (Linux) and 2.5 (Wine).
Jim Wilson
GNV, FL
--
http://mail.python.org/ma
16 matches
Mail list logo
