Guido van Rossum wrote:
I guess that leaves Alex's question of whether or not supplying a string of some
description as the initial value can be legitimately translated to:
if isinstance(initial, basestring):
return initial + type(initial)().join(seq)
If you're trying to get people in the
Guido van Rossum wrote:
2. How would the initial value that forms the basis of summation be built for
non-empty sequences?
Here's you're way off. There's never any use of +=, so never any
need to create a new object. The algorithm I had in mind was:
- if empty, return 2nd arg
- if one item,
On Tue, 15 Mar 2005 07:47:20 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
But I'm not so sure now. Thinking ahead to generic types, I'd like the
full signature to be:
def sum(seq: sequence[T], initial: T = 0) - T.
Would this _syntax_ work with generic types:
def sum(seq:
Thinking ahead to generic types, I'd like the full signature to be:
def sum(seq: sequence[T], initial: T = 0) - T.
Would this _syntax_ work with generic types:
def sum(seq: sequence[T], initial: T = T()) - T.
Maybe, but it would preclude union types; continuing with the (bad)
Tim Peters wrote:
I can't say it bothers me to specify an appropriate identity element
when 0 is inappropriate.
Maybe instead of a single sum() function, each summable
type should have a sum() static method which uses an
identity appropriate to that type.
So to sum a list of integers you would use
John Williams wrote:
Michael Walter wrote:
Would this _syntax_ work with generic types:
def sum(seq: sequence[T], initial: T = T()) - T.
This doesn't make sense with existing semantics because default
arguments are evaluated when the function is defined, but T() can't be
evaluated until the
On Wed, 16 Mar 2005 08:28:22 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
Thinking ahead to generic types, I'd like the full signature to be:
def sum(seq: sequence[T], initial: T = 0) - T.
Would this _syntax_ work with generic types:
def sum(seq: sequence[T], initial: T =
On Thu, 17 Mar 2005 14:34:23 +1300, Greg Ewing
[EMAIL PROTECTED] wrote:
Not to mention that if the seq is empty, there's no
way of knowing what T to instantiate...
You just use the same T as inferred for seq : sequence[T] wink.
Michael
___
Python-Dev
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
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
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.
[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
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
[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
Guido van Rossum wrote:
But I think the logical consequence of your approach would be that
sum([]) should raise an exception rather than return 0, which would be
backwards incompatible. Because if the identity element has a default
value, the default value should be used exactly as if it were
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
# Add the elements
if
Alex Martelli wrote:
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
It turns out the
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
[...]
Maybe what we really should be doing is trapping the TypeError, and
generating a
more meaningful error message.
E.g.
[...]
... try:
... value += first
... except TypeError:
... raise
Guido van Rossum wrote:
But I think the logical consequence of your approach would be that
sum([]) should raise an exception rather than return 0, which would be
backwards incompatible. Because if the identity element has a default
value, the default value should be used exactly as if it were
Eric Nieuwland wrote:
Perhaps the second argument should not be optional to emphasise this.
After all, there's much more to sum() than numbers.
I think practicality beats purity here. Using it on
numbers is surely an extremely common case.
--
Greg Ewing, Computer Science Dept,
On Mon, 14 Mar 2005 19:16:22 -0500, Tim Peters [EMAIL PROTECTED] 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
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.
Which is not unlike the get() method of dicts. So
There are a few design choices we could have made for sum(); in
particular, for non-empty sequences we could not have used the
identity element (the optional second argument). As it is, we get
unjustified but understandable complaints that sum() only supports
numbers. An alternative design could
Guido van Rossum wrote:
- the identity (defaulting to 0) if the sequence is empty
- the first and only element if the sequence only has one element
- (...(((A + B) + C) + D) + ...) if the sequence has more than one element
While this might be reasonable if the identity
argument is not specified, I
[Guido van Rossum]
- the identity (defaulting to 0) if the sequence is empty
- the first and only element if the sequence only has one element
- (...(((A + B) + C) + D) + ...) if the sequence has more than one element
[Greg Ewing]
While this might be reasonable if the identity
argument
That is like Lisp's +, must be good :P
Michael
On Sun, 13 Mar 2005 08:38:42 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
There are a few design choices we could have made for sum(); in
particular, for non-empty sequences we could not have used the
identity element (the optional second
30 matches
Mail list logo
