Guido van Rossum wrote:
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
... try:
... value += first
... except TypeError:
... raise TypeError(Cannot add first element %r to initial value %r %
(first, value))
No, no, no! NO! Never catch a general exception
Brian Sabbey wrote:
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a
substitute of lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further
arguments.
I do not see why you say suite-based thunks cannot
Guido van Rossum wrote:
I think the conclusion should be that sum() is sufficiently
constrained by backwards compatibility to make fixing it impossible
before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is
only used for empty lists.
Two questions about this:
1. When omitting the
On Tue, 15 Mar 2005 22:21:07 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I think the conclusion should be that sum() is sufficiently
constrained by backwards compatibility to make fixing it impossible
before 3.0. But in 3.0 I'd like to fix it so that the 2nd
Title: RE: [Python-Dev] Rationale for sum()'s design?
[Guido van Rossum]
#- 1. When omitting the second argument, would supplying an
#- empty list return 0,
#- None or raise an exception?
#-
#- Good question...
I'd go for None:
- Is a good default for a non-existing argument.
- If
On Mon, 14 Mar 2005 17:57:42 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
Unfortunately this started when I claimed in my blog that sum() was a
replacement for 80% of all reduce() uses.
That's probably where the error lies, then. When it was introduced,
sum() was for summing numbers.
Michael Chermside [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Tim writes:
I'd personally be delighted if sum() never worked on anything other
than numbers.
Guido writes:
I think the conclusion should be that sum() is sufficiently
constrained by backwards compatibility to
[Guido]
Unfortunately this started when I claimed in my blog that sum() was a
replacement for 80% of all reduce() uses.
[Paul]
That's probably where the error lies, then. When it was introduced,
sum() was for summing numbers.
Um, Python doesn't provide a lot of special support for numbers
Title: RE: [Python-Dev] Rationale for sum()'s design?
[Guido van Rossum]
#- 3.0 is soon?!?
*You* should answer this, ;)
. Facundo
Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/
. . . . . . . . . . . . . . . . . . . . . . .
[Guido van Rossum]
Um, Python doesn't provide a lot of special support for numbers apart
from literals -- sum() should support everything that supports the +
operator, just like min() and max() support everything that supports
comparison, etc.
The discussion in the patch that introduced it
Samuele Pedroni wrote:
My point is that a suite-based syntax
can only be a half substitute for lambda and anyway requiring a suite
seems overkill and unnatural for the just 1 expression case, for example
predicates. IOW a suite-based syntax is not a lambda killer in itself, I
would not try to
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ test for exprlist in testlist list-iter-opt ]
where
test can be an arbitrary expression: and, or, lambda, +, -, ...
exprlist can be a list of expression, except for boolean and
relational expressions (but I think this is
Eric Nieuwland wrote:
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ test for exprlist in testlist list-iter-opt ]
where
test can be an arbitrary expression: and, or, lambda, +, -, ...
exprlist can be a list of expression, except for boolean and
relational expressions
On Mar 15, 2005, at 01:16, Tim Peters wrote:
[Eric Nieuwland]
Perhaps the second argument should not be optional to emphasise this.
After all, there's much more to sum() than numbers.
[Greg Ewing]
I think practicality beats purity here. Using it on
numbers is surely an extremely common case.
I'd
Eric Nieuwland wrote:
[ test for exprlist in testlist list-iter-opt ]
Aren't these names a bit mixed up w.r.t. what's in that position?
It comes more-or-less straight out of Grammar/Grammar, so: no,
I don't think so.
As far as I know
test is not a test but a function as it produces any value
It may be time to PEP (or re-PEP), if only to clarify what people are
actually asking for.
Brian Sabbey's example from message
http://mail.python.org/pipermail/python-dev/2005-March/052202.html
*seems* reasonably clear, but I don't see how it relates in any way to
for loops or generators,
Nick Coghlan wrote:
Guido van Rossum wrote:
No, no, no! NO! Never catch a general exception like that and replace
it with one of your own. That can cause hours of debugging pain later
on when the type error is deep down in the bowels of the += operation
(or perhaps deep down inside something *it*
Gareth McCaughan wrote:
Some bit of my brain is convinced that [x in stuff if condition]
is the Right Syntax and keeps making me type it even though
I know it doesn't work.
(and I agree with Gareth)
On Monday 2005-03-14 12:42, Eric Nieuwland wrote:
The full syntax is:
[ f(x) for x in seq
Jim Jewett wrote:
It may be time to PEP (or re-PEP), if only to clarify what people are
actually asking for.
Brian Sabbey's example from message
http://mail.python.org/pipermail/python-dev/2005-March/052202.html
*seems* reasonably clear, but I don't see how it relates in any way to
for loops or
[Alex Martelli]
I'm reasonably often using sum on lists of datetime.timedelta
instances, durations, which ARE summable just like numbers even
though they aren't numbers. I believe everything else for which I've
used sum in production code DOES come under the general concept of
numbers, in
At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
I discussed this approach with Guido in private e-mail a few months back
during discussion about an article I was writing for DDJ about
decorators. We also discussed something very similar to 'update_meta()',
but never
21 matches
Mail list logo
