> 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 lis
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" opera
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
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
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
>> short-circuiting to work -- and adding a coercion to b
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 Ca
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' an
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 red
Fredrik Lundh wrote:
> 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 e
> 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 "&&" wit
Greg Ewing canterbury.ac.nz> writes:
>
> 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 = some
> >> 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 singl
Would this change break x < y < z ? Hope not.
+1 on x?y:z
-1 on && || replacing and/or
unless and/or kept with current semantics and
&& || introduced Raymond's boolean idea, but then
-1 too many unrelated but different spellings
On 9/19/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> O
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 wo
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 wh
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 ambiguou
> > 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:
> 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 it (on some levels, anyway).
Agree
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
"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 Pytho
Guido van Rossum <[EMAIL PROTECTED]> writes:
> 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 s
"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
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
> > 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_T
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.
>
> 1) The construct can be error-prone. When an error occurs it can be
> invisible
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
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 Pytho
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 wo
>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
> 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
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
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
[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 bi
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 thin
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
35 matches
Mail list logo
