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
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 exha
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
>
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,
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 h
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, +-
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
> somethin
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
"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 unnecessar
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]
> 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 ite
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
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
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
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 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 k
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 discussi
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
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; pr
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 ar
(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
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
___
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 know
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 probl
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
go
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 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
http://mail.python.org/mailman
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.
>
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 unrealis
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 p
[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 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"
test test_macfs failed -- Traceback (most recent call last):
File "/Users/gvr/p4/Lib/test/test_macfs.py", line 53, in test_dates
self.assertEqual(dates, (now, now-1, now-2))
AssertionError: (1127241062, 1127241062, 1127241061) != (1127241063,
1127241062, 1127241061)
Any takers? What does th
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
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
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,
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 "
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. sys
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)
> expl
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
self.as
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
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
> 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
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
> >> 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
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
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 wi
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
Alexander Myodov wrote:
> To increase my understanding of Python-way, can you (or someone else)
> explain the reasons why such proposals were rejected?
I wasn't around for the discussion Josiah refers to, but I would guess it is
because they don't improve the power or readability of the language,
"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
72 matches
Mail list logo
