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 be
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 s
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 settled on a name. Originally he wanted me
to PEP th
On Tuesday 2005-03-15 01:57, 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.
Why's that
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 make "fixing" it impossible
> before 3.0. But in 3.0 I'd like to fix it so that
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 2
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.
- I
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. Whe
"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 compat
[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 num
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
> OTOH 0 is more compatible and None is a strong candidate too...
None is useless as a default return value for summation. Any code
outside the summation would have to explicitly test for that value.
Stick with zero. Theoretical musings are no reason to make this
function hard to use.
> But I'
Nick Coghlan wrote:
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 cat
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 stres
Eric Nieuwland wrote:
The full syntax is:
[ f(x) for x in seq if pred(x) ]
being allowed to write 'x' instead of 'identity(x)' is already a
shortcut, just as dropping the conditional part.
That's not the full syntax. The full syntax is
[ for in ]
where
can be an arbitrary expression:
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ for in ]
where
can be an arbitrary expression: and, or, lambda, +, -, ...
can be a list of expression, except for boolean and
relational expressions (but I think this is further constrained
semantically)
list a list
Eric Nieuwland wrote:
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ for in ]
where
can be an arbitrary expression: and, or, lambda, +, -, ...
can be a list of expression, except for boolean and
relational expressions (but I think this is further constrained
seman
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 pe
Eric Nieuwland wrote:
[ for in ]
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
is not a test but a function as it produces any value not just
True/False
To quote more of
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, exce
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* i
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 s
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 o
[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
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 settled
27 matches
Mail list logo
