Hello Josiah,
JC Alexander,
JC The essence of what you have proposed has been proposed (multiple times)
before,
JC and I seem to remember it was shot down.
To increase my understanding of Python-way, can you (or someone else)
explain the reasons why such proposals were rejected?
JC The below
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
Starting in about 11 hours time, the release24-maint branch is FROZEN
for the 2.4.2c1 release. The freeze will last for around a day, and
then we're in a state of mostly-frozen for another week, until 2.4.2
(final). During that week, please don't check things into the branch
unless you check
Hi,
IMO, the relpath method should just work textually on
the pathnames. It's up to the user to ensure it makes
sense to do so, e.g. by resolving symlinks beforehand
if necessary.
I guess so. Don't forget to mention this quirk in the docs, though :)
The alternative would be for relpath to
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.
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 the last evaluated
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 ||
I just built and ran the latest Python 2.4.2c1 from CVS on our HP-UX
Itanium 2 box. sys.maxint is 9223372036854775807 on this box.
I get the following failure from test_unicode (all other tests pass):
File /var/tmp/guido/p4/Lib/test/test_unicode.py, line 553, in
test_codecs_errors
Alexander Myodov [EMAIL PROTECTED] wrote:
Hello Josiah,
JC Alexander,
JC The essence of what you have proposed has been proposed (multiple times)
before,
JC and I seem to remember it was shot down.
To increase my understanding of Python-way, can you (or someone else)
explain the
This seems to disappear when I disable -O. I guess the HP-UX optimizer
is as bad as it always was. Or perhaps we have an old version
installed. Sorry!
On 9/20/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I just built and ran the latest Python 2.4.2c1 from CVS on our HP-UX
Itanium 2 box.
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
On Tue, Sep 20, 2005 at 10:20:44AM -0700, Josiah Carlson wrote:
Try using the code I offered. It allows the cross of an aribitrary
number of restartable iterables, in the same order as an equivalent list
comprehension or generator expression.
list(cross([1,2], [3,4], [5,6]))
[(1, 3, 5),
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 be simplified to
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
On my Linux box (Red Hat Enterprise 3), test_ossaudiodev hangs forever
when I enable it:
./python -E -tt ../Lib/test/regrtest.py -u all test_ossaudiodev
test_ossaudiodev
Traceback (most recent call last):
File ../Lib/test/regrtest.py, line 1178, in ?
main()
File ../Lib/test/regrtest.py,
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
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.
Thanks for
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) 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
On Sun, 18 Sep 2005, Guido van Rossum wrote:
On 9/17/05, John J Lee [EMAIL PROTECTED] wrote:
[...snip...]
[guido]
If my hunch is right, I expect that instead of writing massively
parallel applications, we will continue to write single-threaded
applications that are tied together at the
Hi,
A quick note, the profile.py module is broken -- crashes on some
examples and real-world programs. I think I should be able to fix it by
tomorrow, but not tonight.
(See example checked in in the CVS trunk -- Lib/test/test_profile --
which passes, but for some reason I get completely
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 expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use
On Mon, 19 Sep 2005, Florian Weimer wrote:
The real problem is that you can ditch most extension modules. 8-(
[...]
*Is* that a showstopper for Python 3.0, though?
John
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, 20 Sep 2005, John J Lee wrote:
[...]
I don't actively want a GIL-free Python. I was just making some arguments
[...]
Actually, FWIW, I don't know if I even *passively* want a GIL-free Python,
if it encourages threaded code (though I'd like to have that option for my
occasional personal
On 9/20/05, John J Lee [EMAIL PROTECTED] wrote:
On Mon, 19 Sep 2005, Florian Weimer wrote:
The real problem is that you can ditch most extension modules. 8-(
[...]
*Is* that a showstopper for Python 3.0, though?
Who knows. I bet Guido doesn't even know how much breakage he is
going to
On Mon, 19 Sep 2005, Tim Lesher wrote:
On 9/19/05, Michael Hudson [EMAIL PROTECTED] wrote:
I was disappointed that that article (hey, it was the only issue of
ddj I've ever actually bought! :) didn't consider any concurrency
models other than shared memory threading.
The problem is
On Tue, 20 Sep 2005, Brett Cannon wrote:
On 9/20/05, John J Lee [EMAIL PROTECTED] wrote:
On Mon, 19 Sep 2005, Florian Weimer wrote:
The real problem is that you can ditch most extension modules. 8-(
[...]
*Is* that a showstopper for Python 3.0, though?
Who knows. I bet Guido
Hi,
On Tue, Sep 20, 2005 at 09:21:14PM +0200, Armin Rigo wrote:
A quick note, the profile.py module is broken -- crashes on some
examples and real-world programs. I think I should be able to fix it by
tomorrow, but not tonight.
It was easier than I thought, sorry for the alarm.
Armin
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) 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
(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:
On 9/20/05, John J Lee [EMAIL PROTECTED] wrote:
threading is not the only, nor the best, concurrency model.
But maybe these chips designed with threading in mind blow that argument
out of the water. I don't know enough to know whether that's true or
not...
I don't know that any chips are
I just finished debugging some code that broke after upgrading to
Python 2.4 (from 2.3). Turns out the code was testing list iterators
for their boolean value (to distinguish them from None). In 2.3, a
list iterator (like any iterator) is always true. In 2.4, an exhausted
list iterator is false;
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
On Tuesday 20 September 2005 17:49, Guido van Rossum wrote:
I realize that this was a deliberate feature, and that it exists in
2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like*
I wasn't paying any attention at the time, so I don't know what was discussed.
Some
On Sep 20, 2005, at 5:43 PM, Guido van Rossum wrote:
On 9/20/05, John J Lee [EMAIL PROTECTED] wrote:
threading is not the only, nor the best, concurrency model.
But maybe these chips designed with threading in mind blow that
argument
out of the water. I don't know enough to know whether
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 strange to me
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 response to the
Steven Bethard wrote:
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) 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
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) 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
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,
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
)
especially as
Guido van Rossum:
I think I'd prefer (if expr then expr else expre)
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 =
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 readability is
Fred L. Drake, Jr. wrote:
On Tuesday 20 September 2005 17:49, Guido van Rossum wrote:
I realize that this was a deliberate feature, and that it exists in
2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I
*like*
I wasn't paying any attention at the time, so I don't know
On 9/20/05, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
In any case, it's simple to get the 2.3 behaviour back - just add
__nonzero__. I think that could validly be considered a bugfix.
Alas not -- it would still be a functionality change relative to 2.4 and 2.4.1.
Also, an object whose
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
elif c:
x = d
else:
x
[Guido]
I just finished debugging some code that broke after upgrading to
Python 2.4 (from 2.3). Turns out the code was testing list iterators
for their boolean value (to distinguish them from None). In 2.3, a
list iterator (like any iterator) is always true. In 2.4, an exhausted
list
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
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I just finished debugging some code that broke after upgrading to
Python 2.4 (from 2.3). Turns out the code was testing list iterators
for their boolean value (to distinguish them from None).
This seem unnecessarily
On 9/20/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Guido]
I just finished debugging some code that broke after upgrading to
Python 2.4 (from 2.3). Turns out the code was testing list iterators
for their boolean value (to distinguish them from None). In 2.3, a
list iterator (like any
On 9/20/05, Terry Reedy [EMAIL PROTECTED] wrote:
I presume there were two reasons: internal efficiency of preallocations
(list(some_it) for example)
This could have been implemented without making the implementation
details public.
and letting people differentiate iterator with
something
Alexander Myodov wrote:
for i in largelist while !found:
This doesn't cover enough use cases to be worth it, IMO.
The exit condition is often buried in the middle of
other statements in the loop, not right at the
beginning.
--
Greg Ewing, Computer Science Dept,
Matthias Andreas Benkard wrote:
But this begs the question: What is relpath good for, anyway?
[Assuming you mean invites, prompts, etc. the question...:-)]
A couple of use cases I've encountered:
* Creating symbolic links. I'm traversing a directory
hierarchy, and building a parallel
At 06:10 PM 9/20/2005 -0400, Bob Ippolito wrote:
My use case for this isn't so much about threads, but plug-ins.
Writing multiple Python-based plug-ins for an application is always a
mess, because they share too much (sys.modules, sys.path, etc.).
PyObjC would benefit greatly from this feature,
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
syntax.
Terry Reedy wrote:
The original version of this PEP proposed the following syntax:
expression1 if condition else expression2
The out-of-order arrangement was found to be too uncomfortable
for many of participants in the discussion; especially when
expression1 is long,
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
Guido van Rossum wrote:
I just finished debugging some code that broke after upgrading to
Python 2.4 (from 2.3). Turns out the code was testing list iterators
for their boolean value (to distinguish them from None). In 2.3, a
list iterator (like any iterator) is always true. In 2.4, an
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
65 matches
Mail list logo
