Guido:
> Now you've pushed me over the edge. I've made up my mind
> now, "X if C else Y" it will be. I hope to find time to
> implement it in Python 2.5.
Steve Holden:
> Not before time, either. If this ends the discussion then
> I'll consider I've done everyone a favour. Sometimes no
> decision
> > I did this for my favorite proposal, and ended up with the list shown
> > further down below.
> >
> > I think they all looks great!
> >
> The fact that so few were found in whole of the standard library does
> put the use case into question, though, no? Though I am sure more could
> be found wi
Guido van Rossum wrote:
> [Guido]
>
>>>Let me give you what you expect. If all the "X if C else Y" syntax
>>>does is prevent that atrocity from ever being introduced, it would be
>>>worth it. :)
>
>
> [Steve]
>
>>Well, fine. However, it does allow atrocities like
>>
>>func(f for f in lst if f >
Nick Coghlan wrote:
> i.e., it's
> like an "or", only we're asking that the decision be made based on something
> other than the truth value of the left hand operand.
Hmmm, then maybe it should be
a or c if b
or perhaps
a or, if b, c
:-)
--
Greg Ewing, Computer Science Dept, +--
[Guido]
> > Let me give you what you expect. If all the "X if C else Y" syntax
> > does is prevent that atrocity from ever being introduced, it would be
> > worth it. :)
[Steve]
> Well, fine. However, it does allow atrocities like
>
> func(f for f in lst if f > -1 if f < 0 else +1)
No it doesn't!
Guido van Rossum wrote:
> On 9/29/05, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>I would argue for mandatory parentheses around the expression, leaving
>>room later (probably after Guido is no longer around to be sick at the
>>site of it) for:
>>
>>def f(condition):
>> return something if con
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> After all there's nothing wrong with and/or.
This is one reason 'no addition' got a relatively high rank in the vote.
Examples...
> telnet~1.py:'DO' if cmd == DO else 'DONT',
versuscmd =
[ongoing discussion of conditional expressions]
I waited until I had caught up on my reading before saying anything. Now I'll
express my opinion in a single posting then keep quiet unless I actually find I
have something novel to contribute (difficult in a topic that's been talked to
death 3 or 4
Guido van Rossum wrote:
> I did this for my favorite proposal, and ended up with the list shown
> further down below.
>
> I think they all looks great!
I'm sorry for my bad English
IMHO, if condition is nontrivial, then the syntax:
expr1 if some complex condition else expr2
can be more ha
> > It only takes about five minutes to try out a given syntax proposal
on
> > all the fragments listed below. That short exercise provides an
> > excellent insight into the look and feel of each proposal in real
world
> > code.
>
> I did this for my favorite proposal, and ended up with the list
On 9/29/05, Steve Holden <[EMAIL PROTECTED]> wrote:
> I would argue for mandatory parentheses around the expression, leaving
> room later (probably after Guido is no longer around to be sick at the
> site of it) for:
>
> def f(condition):
> return something if condition # no else!
> retur
Antoine Pitrou wrote:
>>The only problem is that it's not easy to come up with a regex-based
>>way to transform
>>
>>C and X or Y
>>
>>into
>>
>>X if C else Y
One way is to parse it manually to a list. This was just a test, but
more samples can be added friarly easy.
samples = [
#
Guido van Rossum wrote:
> On 9/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>FWIW, I scanned the standard library for all the and/or pairings where a
>>conditional expression was applicable. This sampling can serve as a
>>reference for what "typical" uses would look like in real Python
Guido van Rossum wrote:
file = os.path.abspath(file) if file else '?'
...
These are all unreadable. In C "a ? b : c" is not used very often. A
quick check of the Python source found 476 occurences.
-1 to conditional expressions.
___
Python-Dev mailing
Antoine Pitrou wrote:
> This is especially true if the "X" in "X if C else Y" happens to be a
> non-trivial expression - witness your example from unittest.py:
> return doc.split("\n")[0].strip() if doc else None
>
> ... because then the condition (which is the most important part of the
>
Raymond Hettinger wrote:
> [Aahz]
>
>>I'm also opposed to elif in conditional expressions -- let's keep this
>
> a
>
>>simple Pythonic rewrite of C's ternary.
>>
>>I'm +0 on requiring parentheses precisely because they're annoying.
>
> I'm
>
>>still expecting simple boolean expressions to be t
Guido> After all there's nothing wrong with and/or.
Especially if it's correct.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
> The only problem is that it's not easy to come up with a regex-based
> way to transform
>
> C and X or Y
>
> into
>
> X if C else Y
(my 2 cents)
I find this proposal very confusing. The order is not logical at all.
One usually expects to find the condition on one side, and the
alter
Guido van Rossum wrote:
> I think they all looks great!
expression if expression?
looks like you've been doing too much Perl hacking lately ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
On 9/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[a garbled list]
Stupid gmail broke the lines. Here it is again as an attachment.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
XifCelseY.py
Description: application/python
___
On 9/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, I scanned the standard library for all the and/or pairings where a
> conditional expression was applicable. This sampling can serve as a
> reference for what "typical" uses would look like in real Python code as
> created by a number
[Aahz]
> I'm also opposed to elif in conditional expressions -- let's keep this
a
> simple Pythonic rewrite of C's ternary.
>
> I'm +0 on requiring parentheses precisely because they're annoying.
I'm
> still expecting simple boolean expressions to be the primary use case,
> and my hunch is that ov
On Wed, Sep 21, 2005, Nick Coghlan wrote:
> Steven Bethard wrote:
>> Guido van Rossum wrote:
>>>
>>>I think I'd prefer (if then else ) i.e. no
>>>colons. None of the other expression forms (list comprehensions and
>>>generator expressions) involving statement keywords use colons.
>>
>> FWIW, I
Gustavo J. A. M. Carneiro wrote:
> More realistic example:
>
> def greet(person=None):
> print "Hello %s" % (if person is None: "World" else: person)
>
> Not as compact as C's ?:, but more readable and intuitive. It's just
> like an if-else construct, but on a single line and () ar
New keyword is so expensive?
And why special case for 'then' is better than special case for 'take'?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
On Sun, 2005-09-25 at 19:11 +0200, Reinhold Birkenfeld wrote:
> Sokolov Yura wrote:
> > Sorry for looking in every hole.
> > Just a suggestion.
> >
> > A= condition and first or second
> > problem is in case when first in (None,0,[],"").
> > May be invent new operator 'take'.
> > take - returns r
On Saturday 2005-09-24 04:21, Terry Reedy wrote:
> Never wrote a single line, and may have not read one (in DDJ? Byte?) for
> 15-20 years. How do *you* read such C? Cond 'Qmark' ?
I seldom have to read C code aloud, and the ?: operator is
rare-ish; but I would suggest reading a?b:c as "a c
Sokolov Yura wrote:
> Sorry for looking in every hole.
> Just a suggestion.
>
> A= condition and first or second
> problem is in case when first in (None,0,[],"").
> May be invent new operator 'take'.
> take - returns right operator when left evals to True and stops
> computing condidtional expr
Sorry for looking in every hole.
Just a suggestion.
A= condition and first or second
problem is in case when first in (None,0,[],"").
May be invent new operator 'take'.
take - returns right operator when left evals to True and stops
computing condidtional expression.
Then we could write:
A = co
On 9/24/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Now, can you honestly say that you would (naively) read
>
> return foo if bar else baz
>
> and be certain you knew what it meant?
FWIW, yes, I can honestly say that I would be certain. Yes, you may be
able to *parse* it as (foo if) bar (esle b
Terry Reedy wrote:
> Now, can you honestly say that you would (naively) read
>
> return foo if bar else baz
>
> and be certain you knew what it meant?
I can honestly say that, given I knew I was reading Python
code, it would never have entered by head to read "foo if"
as meaning that "foo" wa
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I am reminded of how some people seem to react to fingernails on a
blackboard, while the screech is just another noise to me, except that I am
in the opposite position with respect to a if b else c.
> Does it help if
On 9/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> But I think there's a difference in kind here - to *fix* Raymond's example
> required a fundamental change to the structure of the line, none of which
> looked as clean as the original. There is no way to get the and/or construct
> to gracefully
Terry Reedy wrote:
> During the c.l.p debate, someone counted about 100 correct uses of 'a and b
> or c' in the standard library. But one real misuse edged Guido toward
> replacing it. So I think the replacement should be as clear as reasonably
> possible and clearly an improvement.
But I thi
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>
>> Many people, perhaps most, including me, read
>>
>> exp1 if exp2 else exp3 # as
>> cond if etrue else efalse # in direct analogy with
>> cond ? etrue : efalse # from C
>
> I'd have thought only
"Jim Jewett" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
A nice summary, to which I will add just a little.
> For a conditional expression, I think the choices are really down
> to the following, which was already way too much freedom last
> (http://www.python.org/peps/pep-0308.
>> Need I continue? Or is the dead still dead?
Since 'a if b else c' is not obviously dead, I will summarize my argument
against it thusly:
It is ambiguous to people because it is can be parsed (by people, who are
not automatons) as either '(a if) b (else c)' or 'a (if b) (else c)'. The
firs
Gareth McCaughan <[EMAIL PROTECTED]> wrote:
[seems to have gone off list with a portion of the discussion]
> > The reason I like "a if b else c" is because it has the
> > most natural word order. In English,
> >My dog is happy if he has a bone, else sad.
> > sounds much more natural than
> >
On 9/20/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Basically, I'm +1 on the original PEP 308 form because it reads more naturally
> (and more like LC's and GE's) to me in expression contexts, and +0 on the
> "if/then/elif/else" form (because I would like a real conditional operator).
I agree th
> The reason I like "a if b else c" is because it has the
> most natural word order. In English,
>My dog is happy if he has a bone, else sad.
> sounds much more natural than
>My dog is, if he has a bone, happy, else sad.
Neither sounds very natural to me; conditional
expressions don't occu
"Andrew Koenig" <[EMAIL PROTECTED]> wrote:
>
>
> > My problem with this syntax is that it can be hard to read:
> >
> > return if self.arg is None then default else self.arg
> >
> > looks worryingly like
> >
> > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
> >
> > to me.
>
> Inte
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> to me.
Interesting. What about
return if self.arg is None: default else:
Terry Reedy wrote:
> Many people, perhaps most, including me, read
>
> exp1 if exp2 else exp3 # as
> cond if etrue else efalse # in direct analogy with
> cond ? etrue : efalse # from C
I'd have thought only Forth programmers would be prone to that!
It would surprise me greatly if it's real
Gary Herron wrote:
> And in fact, one read and understands your return statement just like an
> English sentence -- word by word from beginning to end. This seems an
> argument FOR the syntax not against.Moreover, if one uses the
> proposed parenthesized syntax, even the slightly odd word
Greg Ewing wrote:
> Ron Adam wrote:
>
>
>>(a if e then b)
>>((a1 if e1 then b1) if e then b)
>>(a if e then (a2 if e2 then b2))
>>((a1 if e1 then b1) if e then (a2 if e2 then b2))
>
>
> I think you mean 'else' rather than 'then' in all
> those, don't you?
Yes of course, thanks for correcting.
Ron Adam wrote:
> (a if e then b)
> ((a1 if e1 then b1) if e then b)
> (a if e then (a2 if e2 then b2))
> ((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all
those, don't you?
--
Greg Ewing, Computer Science Dept, +
Jim Jewett wrote:
>
> (3) What order should the clauses appear?
> (if test then True else False)
> (if test1 then Val1 elif test2 Val2 elif test3 Val3 else Val4)
> + Natural Order
> - do we need "then"?
> (True if normal else False)
> (Val1 if test1 else Val2 if t
Steven Bethard wrote:
> Please no more syntax proposals! There were enough in the PEP. It
> looks like most people support a conditional expression of some sort.
> We need to leave the syntax to Guido. We've already proved that like
> the decorators discussions, we can't as a community agree o
Ron Adam wrote:
> ( e selects (e1 selects a1, b1),
> (e2 selects a2, b2),
> (e3 selects a3, b3) )
I think you've just reinvented the case statement, which
disagrees with "if" over the order of true and false clauses.
For a conditional expression, I think the c
I think a recap of past arguments is useful. Me-too votes are not. i
will read everything and pick a syntax and that's it. We can do it in
Python 2.5.
On 9/21/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Guido:
>
> When you invited resumed discussion, did you intend to proceed from where
> the rev
Guido:
When you invited resumed discussion, did you intend to proceed from where
the revised PEP left off (with a few variations on the table), or to start
over from point zero (with potentially anything and everything on the
table). In particular, do we need to rehash the reasons for rejectio
BJörn Lindqvist <[EMAIL PROTECTED]> writes:
>> My problem with this syntax is that it can be hard to read:
>>
>> return if self.arg is None then default else self.arg
>>
>> looks worryingly like
>>
>> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> That can already be written in Pytho
> > I think I'd prefer (if then else ) i.e. no
> > colons.
>
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
That can already be written
On 9/21/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Please no more syntax proposals! There were enough in the PEP. It
> looks like most people support a conditional expression of some sort.
> We need to leave the syntax to Guido. We've already proved that like
> the decorators discussions, w
Adam wrote:
> So looking at a few alternatives ...
>
[snip]
> (e ? (e1 ? a1 : b1) : (e2 ? a2 : b2))
>
[snip]
> (if e, (if e1, a1 else b1) else (if e2, a2 else b2))
>
[snip]
> (if e then (if e1 then a1 else b1) else (if e2 then a2 else b2))
>
[snip
> (e selects (e1 selects a1 else b1) else (e2 selec
Michael Hudson wrote:
>Guido van Rossum <[EMAIL PROTECTED]> writes:
>
>
>
>>>Given the later addition of generator expressions with mandatory
>>>parentheses , the mandatory-parentheses version of a conditional expression
>>>looks less strange to me than it did then ;-). So I could happily use i
Nick Coghlan wrote:
> Greg Ewing wrote:
>>One nice thing about "x if b else y" is that it
>>chains without needing any more keywords:
>>
>> x if b else y if c else z
>>
>>But if you require parens, it's not so nice:
>>
>> (x if b else (y if c else z))
> If Guido chose this form, I would expec
Greg Ewing wrote:
> Guido van Rossum wrote:
>
>
>>I think if we go with (if ... then ... else ...) or (if ...:
>>... else: ...) we'll have to support elif as well:
>>
>>(if ... then ... elif ... then ... else ...)
>>or
>>(if ...: ... elif ...: ... else: ...)
>
>
> One nice thing about "x if b e
On Wed, 2005-09-21 at 11:10, Michael Hudson wrote:
> My problem with this syntax is that it can be hard to read:
>
> return if self.arg is None then default else self.arg
>
> looks worryingly like
>
> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
>
> to me.
I think that requriing pa
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> Given the later addition of generator expressions with mandatory
>> parentheses , the mandatory-parentheses version of a conditional expression
>> looks less strange to me than it did then ;-). So I could happily use it
>> even though I may still le
> I think I'd prefer (if then else ) i.e. no
> colons. None of the other expression forms (list comprehensions and
> generator expressions) involving statement keywords use colons.
FWLIW, this was my (strong) preference back at the time of the
original discussion.
--
g
__
Jason Orendorff wrote:
> Honestly, I think I would prefer this syntax. Examples from real
> code, before and after:
>
> lines = [line for line in pr.block.body
> if line.logical_line.strip() != '']
> lines = [for line in pr.block.body:
> if line.logical_line
Guido van Rossum wrote:
> I think if we go with (if ... then ... else ...) or (if ...:
> ... else: ...) we'll have to support elif as well:
>
> (if ... then ... elif ... then ... else ...)
> or
> (if ...: ... elif ...: ... else: ...)
One nice thing about "x if b else y" is that it
chains without
Terry Reedy wrote:
> "The original version of this PEP proposed the following syntax:
> if else
> The out-of-order arrangement was found to be too uncomfortable
> for many of participants in the discussion; especially when
> is long, it's easy to miss the conditional while
"John J Lee" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The stricter form where you don't allow 'elif' will get used in more
> restricted circumstances, so gives less encouragement for widespread
> abuse
> of conditional expressions by people who don't like whitespace-based
>
On Tue, 20 Sep 2005, John J Lee wrote:
[...]
> With the former, we have a more C-style syntax where meaning is determined
> purely by delimeters rather than by whitespace. Instead of braces '{' and
> '}', we have 'then' and 'elif'/'else'. That's a real difference.
[...]
Um, not clear, sorry: the
On Wed, 21 Sep 2005, Thomas Lotze wrote:
> Barry Warsaw wrote:
>
> >> x = (if a then
> >> b
> >> elif c then
> >> d
> >> else
> >> e
> >> )
> [...]
> >
> > I guess that's my point. To me, your latter is actually worse than
> >
> > if a:
> > x = b
> > e
Barry Warsaw wrote:
>> x = (if a then
>> b
>> elif c then
>> d
>> else
>> e
>> )
[...]
>
> I guess that's my point. To me, your latter is actually worse than
>
> if a:
> x = b
> elif c:
> x = d
> else:
> x = e
Can't see a difference as far as r
Guido van Rossum:
> I think I'd prefer (if then else )
In isolation, (if .. then ... else) is an improvement, but I'm
not sure it should be viewed in isolation.
At one point, you wanted to strengthen the distinction
between statements and expressions. Is that still true?
x = (if y then y
On Tue, 2005-09-20 at 18:21, Thomas Lotze wrote:
> Nothing prevents you from spreading the code over multiple lines, like so:
>
> x = (if a then b
> elif c then d
> else e)
>
> or even
>
> x = (if a then
> b
> elif c then
> d
> else
> e
> )
>
> e
Barry Warsaw wrote:
> I'm not so sure. Once you start writing such a complicated thing, I think
> readability will favor just breaking the code out into traditional
> if-blocks. I'd be happy enough with just a binary condition.
Nothing prevents you from spreading the code over multiple lines, l
Guido van Rossum wrote:
> I think I'd prefer (if then else ) i.e. no colons.
> None of the other expression forms (list comprehensions and generator
> expressions) involving statement keywords use colons.
While I like the looks of the form without colons better, I can't quite
follow this argum
Steven Bethard wrote:
> Guido van Rossum wrote:
>
>>I think I'd prefer (if then else ) i.e. no
>>colons. None of the other expression forms (list comprehensions and
>>generator expressions) involving statement keywords use colons.
>
>
> FWIW, I find this quite intuitive. It follows the same
On 9/20/05, Guido wrote:
> On 9/20/05, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> > return (if q: q.popleft() else: None)
> > return (if q then q.popleft() else None)
> > return q ? q.popleft() : None
> >
> > Hmmm. Score one for ?:.
>
> Why? Just because it's shorter?
Just a gut res
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 9/20/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Given the later addition of generator expressions with mandatory
>> parentheses , the mandatory-parentheses version of a conditional
>> expression
>> looks less
On Tue, 2005-09-20 at 17:40, Guido van Rossum wrote:
> Ouch. You're bringing up another valid issue: whether to support
> "elif". I think if we go with (if ... then ... else ...) or (if ...:
> ... else: ...) we'll have to support elif as well:
I'm not so sure. Once you start writing such a compl
(Adding python-dev back to the CC list)
On 9/20/05, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> > If there's one thing I've learned from the PEP 308 vote, it is that
> > votes for language don't work. I prefer some discussion on Python-dev
> > after which I pick one.
>
> +1
>
> Some visual aids
Guido van Rossum wrote:
> I think I'd prefer (if then else ) i.e. no
> colons. None of the other expression forms (list comprehensions and
> generator expressions) involving statement keywords use colons.
FWIW, I find this quite intuitive. It follows the same pattern as LCs
and GEs -- remove t
On 9/20/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
> >I think I'd prefer (if then else ) i.e. no
> >colons. None of the other expression forms (list comprehensions and
> >generator expressions) involving statement keywords use colons.
>
[Guido van Rossum]
> > In fact, I think Raymond's example is more properly considered an
> > argument for adding a conditional expression than for removing the
> > current behavior of the and/or shortcut operators; had we had a
> > conditional expression, he wouldn't have tried to use the "x and y
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
>I think I'd prefer (if then else ) i.e. no
>colons. None of the other expression forms (list comprehensions and
>generator expressions) involving statement keywords use colons.
+1, despite the fact that we seem on a slippery slope towards be
On 9/20/05, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> > and +1 on adding a conditional expression. I believe (y if x else z)
> > was my favorite last time, wasn't it?
>
> No. That was your original proposal, which you later rejected.
Thank
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> In fact, I think Raymond's example is more properly considered an
> argument for adding a conditional expression than for removing the
> current behavior of the and/or shortcut operators; had we had a
> conditional e
On Tue, Sep 20, 2005 at 09:04:53AM -0700, Guido van Rossum wrote:
> On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> > 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
Guido van Rossum wrote:
> Given this realization, I'm now -1 on Raymond's idea, and +1 on adding
> a conditional expression. I believe (y if x else z) was my favorite
> last time, wasn't it? I've changed the subject accordingly.
As the PEP states, I'm not sure if changing the customary order of "
Guido van Rossum <[EMAIL PROTECTED]> writes:
> Unfortunately, if we were to accept Raymond's proposal, we'd have to
> revisit the discussion, since his proposal removes several ways we
> currently avoid the need.
>
> In fact, I think Raymond's example is more properly considered an
> argument for
On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> 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 th
87 matches
Mail list logo