In C, C++, C#, Java, and JavaScript, what do you get when you print the
result of 3 || 10?
In C and C++, you get 1. (in c++ the result is actually true, not 1, but
true prints as 1 by default for backward compatibility)
___
Python-Dev mailing list
I suppose this is a dead horse now, but I will kick it one more time.
Under the rubrics of explicit is better than implicit and there should
only be one wat to do it, I would rather see
bool_val = bool(foo or bar)
instead of having the or operator implicitly call bool() for me. There's
On 9/21/05, Michael Hudson [EMAIL PROTECTED] wrote:
Brett Cannon [EMAIL PROTECTED] writes:
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote:
[SNIP]
I _like_ the explanation of 'and' and 'or' as they are now. They are
basically control flow constructs -- and have to be to get
I agree with Skip.
Bill
I suppose this is a dead horse now, but I will kick it one more time.
Under the rubrics of explicit is better than implicit and there should
only be one wat to do it, I would rather see
bool_val = bool(foo or bar)
instead of having the or operator
Raymond Hettinger [EMAIL PROTECTED] writes:
2) When going back and forth between languages, it is easy to forget
that only Python returns something other than a boolean.
Perl certainly works the same way and I've never heared anybody have
problems with that, but that might be because Perl do
Raymond Hettinger [EMAIL PROTECTED] writes:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
-1
2) When going back and forth between languages, it is easy to forget
that only Python returns
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
No, please not. It's useful sometimes and doesn't hurt most times.
1) The construct can be error-prone. When an error
2) When going back and forth between languages, it is easy to forget
that only Python returns something other than a boolean.
As others point out, this isn't true.
In C, C++, C#, Java, and JavaScript, what do you get when you print the
result of 3 || 10?
Raymond
Michael Hudson wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
You're joking, surely?
for Python 3000, I'd recommend switching to and then and or else instead
of the current ambiguous
On Tuesday 2005-09-20 11:40, Raymond Hettinger wrote:
2) When going back and forth between languages, it is easy to forget
that only Python returns something other than a boolean.
As others point out, this isn't true.
In C, C++, C#, Java, and JavaScript, what do you get when you
On 9/19/05, Andrew McNamara [EMAIL PROTECTED] wrote:
I agree. I find I often have an object with an optional friendly name
(label) and a manditory system name. So this sort of thing becomes common:
'%s blah blah' % (foo.label or foo.name)
The if-else-expression alternative works, but
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
You're joking, surely?
for Python 3000, I'd recommend switching to and then and or else instead
of the current ambiguous single-keyword versions.
That leaves error reduction and clarity as the main motivations for
changing 'and' and 'or' to act like '' and '||' and for introducing a
conditional operator to handle everyone's favorite use cases.
I predict that people who use and and or correctly today will
start confusing with and ||
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote:
[SNIP]
I _like_ the explanation of 'and' and 'or' as they are now. They are
basically control flow constructs -- and have to be to get
short-circuiting to work -- and adding a coercion to bool at the end
seems to add complexity, not reduce
BJörn Lindqvist wrote:
Wouldn't it be possible to omit and and or to just then and else?
x = 3 and 7 or 44
x = 3 and then 7 or else 44
x = 3 then 7 else 44
And then have another set of and and or for non short-circuiting?
I don't think the OP was suggesting that 'and' and 'or' be
Fredrik Lundh wrote:
for Python 3000, I'd recommend switching to and then and or else instead
of the current ambiguous single-keyword versions.
And then we could call the language Pyffel. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got bitten in published code
that had
On 9/19/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
While you're at it, maybe we should switch to and || as well?
That's another thing I always
[Raymond Hettinger]
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got bitten in
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
1) The construct can be error-prone. When an error occurs it can be
invisible to the person who wrote it. I got
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
Please no! 'and' and 'or' is so readably beautiful.
Also, this proposal needs to be considered
P.S. Simplifying and and or may create a need to introduce a
conditional operator but that is a discussion for another day.
While I don't disagree with some of your main points, I do think that
your proposal would eliminate a natural and easy to understand use of
the current behavior of or
While I don't disagree with some of your main points, I do think that
your proposal would eliminate a natural and easy to understand use of
the current behavior of or that I tend to use quite a bit. Your
proposal would break a lot of code, and I can't think of a better
conditional
On Mon, Sep 19, 2005, Jonathan LaCour wrote:
Raymond Hettinger:
P.S. Simplifying and and or may create a need to introduce a
conditional operator but that is a discussion for another day.
While I don't disagree with some of your main points, I do think that
your proposal would eliminate
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
But then I would no longer be able to write
foo = something or default_value
which is one of my favourite Pythonisms!
On 9/19/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
Please no! 'and' and 'or' is so readably
3) Even when it isn't being used, the possibility of non-boolean
return
value complicates the bytecode and parser. To allow for and/or,
the
conditional opcodes leave the tested value on the stack. In most
cases
both branches go directly to a POP_TOP instruction. Since the
POP_TOP
Raymond Hettinger wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
argument.
Please no. I find things like:
def __cmp__(self, other):
return (cmp(self.a, other.a) or
28 matches
Mail list logo
