Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Fri, 01 May 2009 15:03:30 -0700, Aaron Brady wrote:
On May 1, 4:30 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Fri, 01 May 2009 16:30:19 +1200, Lawrence D'Oliveiro wrote:
I have never written anything
Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
for x in a or b or c:
do_something_with(x)
Ugh
for x in [a,b,c]:
if len(x) 0:
do_something_with(x)
break
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 01 May 2009 00:22:22 -0700, Paul Rubin wrote:
Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
for x in a or b or c:
do_something_with(x)
Ugh
for x in [a,b,c]:
if len(x) 0:
do_something_with(x)
break
What ugly, wasteful code. And
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
(2) Why assume that a, b and c are sequences with a fast __len__ method?
They might be (say) linked lists that take O(N) to calculate the length,
or binary trees that don't even have a length, but can be iterated over.
Why assume
Paul Rubin http://phr...@nospam.invalid wrote:
Steven D'Aprano s...@source.com.au writes:
for x in a or b or c:
do_something_with(x)
Ugh
for x in [a,b,c]:
if len(x) 0:
do_something_with(x)
break
Ugh
for x in [a,b,c]:
if x:
On Fri, 01 May 2009 01:56:50 -0700, Paul Rubin wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
(2) Why assume that a, b and c are sequences with a fast __len__
method? They might be (say) linked lists that take O(N) to calculate
the length, or binary trees that don't even
On May 1, 4:30 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Fri, 01 May 2009 16:30:19 +1200, Lawrence D'Oliveiro wrote:
I have never written anything so unbelievable in my life. And I hope I
never will.
I didn't say you did. If anyone thought I was quoting Lawrence's
Aaron Brady castiro...@gmail.com writes:
I think you are looking at an 'ireduce' function, which doesn't
exist in 'itertools' yet.
Nothing is being done with the return value.
sum(1 for x in imap(func, seq))
is enough to force evaluation of func on each element of seq.
--
On Fri, 01 May 2009 16:30:19 +1200, Lawrence D'Oliveiro wrote:
I have never written anything so unbelievable in my life. And I hope I
never will.
I didn't say you did. If anyone thought I was quoting Lawrence's code,
I'd be surprised. It was not my intention to put words into your mouth.
But
On Fri, 01 May 2009 15:03:30 -0700, Aaron Brady wrote:
On May 1, 4:30 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Fri, 01 May 2009 16:30:19 +1200, Lawrence D'Oliveiro wrote:
I have never written anything so unbelievable in my life. And I hope
I never will.
I
Steven D'Aprano wrote:
There are 4,294,967,296 integers that can be represented in 32 bits. Only
one of them represents zero.
Or you can even define it as not including zero... ;)
--
JanC
--
http://mail.python.org/mailman/listinfo/python-list
In message pan.2009.04.30.00.29...@remove.this.cybersource.com.au, Steven
D'Aprano wrote:
The reason why Lawrence's insistence is so badly wrong becomes more
apparent if you look at what you can do with boolean contexts other than
simple `if` tests. Compare:
for x in a or b or c:
Lawrence D'Oliveiro a écrit :
In message 54cb7f8a-
fef4-4bf8-8054-16dc9b5c8...@d2g2000pra.googlegroups.com, Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type?
It's a stupid idea,
Nope, it's a very sensible default (given you can redefine
In article 340175e7-b349-4ca2-bf66-fa9113253...@v23g2000pro.googlegroups.com,
Aaron Brady castiro...@gmail.com wrote:
The sound of that metaphor is rather pleasing ('sweet nothings'), but
I'm not so sure that metaphors belong in computer science and
programming.
Well, you won't be a good
Bruno Desthuilliers wrote:
Lawrence D'Oliveiro a écrit :
What is the rationale for considering all instances true of a user-
defined type?
It's a stupid idea,
Nope, it's a very sensible default (given you can redefine the
'nothingness' value of your types instances), specially when the
On Apr 28, 9:54 pm, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
On Tue, 28 Apr 2009 11:59:18 -0700, Aaron Brady wrote:
To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a
list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing
0, a
On Wed, 29 Apr 2009 17:35:28 +0200, Marco Mariani wrote:
Bruno Desthuilliers wrote:
Lawrence D'Oliveiro a écrit :
What is the rationale for considering all instances true of a user-
defined type?
It's a stupid idea,
Nope, it's a very sensible default (given you can redefine the
On Apr 28, 7:22 am, Colin J. Williams c...@ncf.ca wrote:
Lie Ryan wrote:
I'm puzzled by the last sentence:
*** Python 2.6.2 (r262:71605, Apr 14
2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32. ***
bool(0)
False
bool(-1)
True
bool(-100)
True
Colin W.
What's wrong with Lie
On Mon, Apr 27, 2009 at 11:11 PM, Aaron Brady castiro...@gmail.com wrote:
What is the rationale for considering all instances true of a user-
defined type? Is it strictly a practical stipulation, or is there
something conceptually true about objects?
'''
object.__bool__(self)
If a class
Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type?
User-defined objects (or type) can override .__len__() [usually
container types] or .__nonzero__() to make bool() returns False.
Is it strictly a practical stipulation, or is there
On Mon, Apr 27, 2009 at 11:11 PM, Aaron Brady castiro...@gmail.com wrote:
What is the rationale for considering all instances true of a user-
defined type? Is it strictly a practical stipulation, or is there
something conceptually true about objects?
'''
object.__bool__(self)
If a class
On Apr 28, 1:35 am, Lie Ryan lie.1...@gmail.com wrote:
Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type?
User-defined objects (or type) can override .__len__() [usually
container types] or .__nonzero__() to make bool() returns False.
On Mon, 27 Apr 2009 23:11:11 -0700, Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type? Is it strictly a practical stipulation, or is there
something conceptually true about objects?
Seven years ago, in an attempt to convince Guido *not* to
Lie Ryan wrote:
Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type?
User-defined objects (or type) can override .__len__() [usually
container types] or .__nonzero__() to make bool() returns False.
Is it strictly a practical stipulation,
In message 54cb7f8a-
fef4-4bf8-8054-16dc9b5c8...@d2g2000pra.googlegroups.com, Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type?
It's a stupid idea, and there seem to be instances of users tripping over it
here in comp.lang.python every week.
On Tue, Apr 28, 2009 at 2:22 PM, Colin J. Williams c...@ncf.ca wrote:
Lie Ryan wrote:
Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type?
User-defined objects (or type) can override .__len__() [usually container
types] or .__nonzero__() to
En Tue, 28 Apr 2009 09:22:01 -0300, Colin J. Williams c...@ncf.ca
escribió:
Lie Ryan wrote:
Aaron Brady wrote:
This makes it so all objects except False, None, 0, and empty
containers are true by default. I am not convinced that 'if a
generic object' should have any meaning; it should
Steven D'Aprano wrote:
On Mon, 27 Apr 2009 23:11:11 -0700, Aaron Brady wrote:
... In a boolean (or truth) context, Something and Nothing behave like True
and False in languages with real booleans:
if obj:
print I am Something
else:
print I am Nothing
If you define the short-circuit
On Apr 28, 2:39 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
On Mon, 27 Apr 2009 23:11:11 -0700, Aaron Brady wrote:
What is the rationale for considering all instances true of a user-
defined type? Is it strictly a practical stipulation, or is there
something
On Tue, 28 Apr 2009 19:59:18 +0100, Aaron Brady castiro...@gmail.com
wrote:
The sound of that metaphor is rather pleasing ('sweet nothings'), but
I'm not so sure that metaphors belong in computer science and
programming. Nothing can't have many shapes. Having no onions is the
same as having
On Tue, 28 Apr 2009 11:59:18 -0700, Aaron Brady wrote:
To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a
list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing
0, a singleton Nothing None, and so forth.
The sound of that metaphor is rather pleasing
31 matches
Mail list logo
