Hendrik van Rooyen wrote:
> | (I still think a "join" built-in would be nice, though. but anyone who
> | argues that "join" should support numbers too will be whacked with a
> | great big halibut.)
>
> Strange this - you don't *LOOK* like a Gaulish Blacksmith...
no, but I have a nice safari o
Paddy wrote:
<>
> Why not make sum work for strings too?
>
> It would remove what seems like an arbitrary restriction and aid
> duck-typing. If the answer is that the sum optimisations don't work for
> the string datatype, then wouldn't it be better to put a trap in the
> sum code diverting stri
Paul Rubin wrote:
> Are you saying "abc"+"def" should not be concatenation? I guess
> that's reasonable.
No, I'm definitely not saying that, or at least I didn't mean
that.
> As long as + is string concatenation though, the
> principle of least astonishment suggests that "sum" should
> conconca
Neil Cerutti <[EMAIL PROTECTED]> writes:
> So there isn't, it seems, a practical way of implementing the
> sum(list of strings) -> ''.join(list of strings optimization.
''.join may not be the right way to do it, but obviously there are
other ways. This isn't rocket science.
--
http://mail.python
On 2006-08-25, Paul Rubin wrote:
> Bryan Olson <[EMAIL PROTECTED]> writes:
>> And herein is the problem: A class may implement "__add__" any
>> way the programmer chooses. Python should require, or at least
>> document requirements, on further properties of addition.
>> Python should insist that a
Bryan Olson <[EMAIL PROTECTED]> writes:
> And herein is the problem: A class may implement "__add__" any
> way the programmer chooses. Python should require, or at least
> document requirements, on further properties of addition. Python
> should insist that addition be symmetric an transitive, and
Fredrik Lundh wrote:
> [...] besides, in all dictionaries I've consulted, the word "sum"
> means "adding numbers".
That's a result of not looking deeply enough.
Fredrik Lundh is partially right, in that "Sum" usually refers
to addition of numbers. Nevertheless, the idea that "sum" must
refer to n
"Fredrik Lundh" <[EMAIL PROTECTED]> Wrote:
8<
| (I still think a "join" built-in would be nice, though. but anyone who
| argues that "join" should support numbers too will be whacked with a
| great big halibut.)
|
|
Strange this - you don't *LOOK* lik
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> There is an alternative: raise a warning instead of an exception. That
> permits the admirable strategy of educating users that join() is
> generally a better way to concatenate a large number of strings, while
> still allowing programmers who want to s
On Thu, 24 Aug 2006 18:24:19 +0200, Fredrik Lundh wrote:
> besides, in all dictionaries I've consulted, the word "sum" means
> "adding numbers". are you sure it wouldn't be more predictable if "sum"
> converted strings to numbers ?
And then on Thu, 24 Aug 2006 19:12:17 +0200 Fredrik also wrote
Fredrik Lundh <[EMAIL PROTECTED]> writes:
> "join" doesn't use __add__ at all, so I'm not sure in what sense that
> would be more predictable. I'm probably missing something, but I
> cannot think of any core method that uses a radically different
> algorithm based on the *type* of one argument.
3
Gabriel Genellina wrote:
> sequences don't have to be homogeneous, and iterators cant go back.
> But let GvR say that in his own words:
> http://mail.python.org/pipermail/python-dev/2003-April/034854.html
you could of course dispatch on the type of the second argument (the
start value), but tha
At Thursday 24/8/2006 13:12, Tim Chase wrote:
The interpreter is clearly smart enough to recognize when the
condition occurs such that it can throw the error...thus, why not
add a few more smarts and have it simply translate it into
"start+''.join(sequence)" to maintain predictable behavior
acco
Tim Chase wrote:
> The interpreter is clearly smart enough to recognize when the
> condition occurs such that it can throw the error...thus, why not
> add a few more smarts and have it simply translate it into
> "start+''.join(sequence)" to maintain predictable behavior
> according to duck-typ
>> Just because something is slow or sub-optimal doesn't mean it
>> should be an error.
>
> that's not an error because it would be "slow or sub-optimal" to add
> custom objects, that's an error because you don't understand how "sum"
> works.
>
> (hint: sum != reduce)
No, clearly sum!=reduce.
Tim Chase wrote:
> >>> q3 = q1 + q2
> >>> q3.n, q3.i, q3.j, q3.k
> (8, 13, 16, 22)
> >>> sum([q1,q2])
> Traceback (most recent call last):
>File "", line 1, in ?
> TypeError: unsupported operand type(s) for +: 'int' and 'q'
>
> Just because something is slow or sub-optimal doesn't mean it
> Maybe he's just insisting on the principle of least surprise?
> Personally, I'd rather expect sum() to work for strings and Python to
> issue a warning instead of raising a type error. That warning might
> also be appropriate when using sum() on other builtin sequence types.
In its own way, it m
Fredrik Lundh wrote:
> do you often write programs that "sums" various kinds of data types, and
> for which performance issues are irrelevant?
>
> or are you just stuck in a "I have this idea" loop?
Maybe he's just insisting on the principle of least surprise?
Personally, I'd rather expect sum() t
Steven D'Aprano wrote:
>> and what exactly does the fact that Python can do operator-based
>> dispatch much faster than it can do method-based dispatch have to
>> do with sum's inability to add strings ?
>
> Sorry, I don't get you here. Are you saying that string addition doesn't
> call the oper
On Mon, 21 Aug 2006 12:55:14 +0200, Fredrik Lundh wrote:
> Steven D'Aprano wrote:
>
>> That's a nonsense argument. There is no shortage of slow algorithms, and
>> some of them are built into Python. When did O(n**2) become an error
>> condition? And overhead matters: if I'm only doing a few conca
Carl Banks wrote:
>
> and, you know, if you really want to concatenate strings with sum, you
> can
>
> class noopadd(object):
> def __add__(self,other):
> return other
>
> sum(["abc","def","ghi"],noopadd())
;-)
- Pad.
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
>But I think it is a shame that sum() does a
> special type-check to avoid something which is only sometimes slow. It
> doesn't protect against O(n**2) performance; it merely protects against
> just one of an infinite number of possible "traps for the unwary".
I'm not so sur
Steven D'Aprano wrote:
> That's a nonsense argument. There is no shortage of slow algorithms, and
> some of them are built into Python. When did O(n**2) become an error
> condition? And overhead matters: if I'm only doing a few concatenations,
> it is significantly faster to add the strings using
Alex Martelli wrote:
> In terms of performance, however, the simple loop that you (rhamph)
> posted is generally best -- e.g., with Python 2.5c1 on a MacbookPro:
>
> brain:~/downloads alex$ python -mtimeit -s'deep=[range(9)]*9'
> 's=sum(deep,[])'
> 10 loops, best of 3: 11.2 usec per loop
>
>
Steven D'Aprano wrote:
> On Fri, 18 Aug 2006 19:08:37 -0700, Paul Rubin wrote:
>
>> If the args are strings, the above is a quadratic time algorithm and
>> it's better to throw an error than create such a trap for an unwary user.
>
> That's a nonsense argument. There is no shortage of slow algori
On Fri, 18 Aug 2006 19:08:37 -0700, Paul Rubin wrote:
> If the args are strings, the above is a quadratic time algorithm and
> it's better to throw an error than create such a trap for an unwary user.
That's a nonsense argument. There is no shortage of slow algorithms, and
some of them are built
Rhamphoryncus <[EMAIL PROTECTED]> wrote:
...
> > > I believe the prefered method to flatten a list of lists is this:
> > >
> > > shallow = []
> > > for i in deep:
> > > shallow.extend(i)
> > >
> > > Yes, it's three lines. It's also very easy to read. reduce() and
> > > sum() are not.
> >
>
In <[EMAIL PROTECTED]>, Gerhard Fiedler
wrote:
> On 2006-08-20 07:18:44, Rhamphoryncus wrote:
>
>>> shallow = []
>>> [shallow.extend(i) for i in deep]
>>
>> I'm sure this has been mentioned before, but listcomps are for when you
>> want to store the list and use it for further things, not for wh
On 2006-08-20 07:18:44, Rhamphoryncus wrote:
>> shallow = []
>> [shallow.extend(i) for i in deep]
>
> I'm sure this has been mentioned before, but listcomps are for when you
> want to store the list and use it for further things, not for when you
> want a side effect. TOOWTDI.
Can you please ex
Paddy wrote:
> Rhamphoryncus wrote:
>
> >
> > It's worthwhile to note that the use of + as the concatenation operator
> > is arbitrary. It could just have well been | or &, and has no
> > relationship with mathematically addition.
>
> The effect of the string concatenation operator is only seconda
Rhamphoryncus wrote:
>
> It's worthwhile to note that the use of + as the concatenation operator
> is arbitrary. It could just have well been | or &, and has no
> relationship with mathematically addition.
The effect of the string concatenation operator is only secondary.
Secondary to the use o
Rhamphoryncus wrote:
> It's also worth stressing (not in response to your post, but others)
> that sum([[1],[2],[3]], []) is just as bad as attempting to sum
> strings, both conceptually (it's not mathematical addition), and
> performance-wise. Don't do it. :)
Interesting. I would have guessed t
Bill Pursell wrote:
> Georg Brandl wrote:
> > Paul Rubin wrote:
> > > Sybren Stuvel <[EMAIL PROTECTED]> writes:
> > >> Because of "there should only be one way to do it, and that way should
> > >> be obvious". There are already the str.join and unicode.join methods,
> > >
> > > Those are obvious???
Bill Pursell wrote:
> Georg Brandl wrote:
>> Paul Rubin wrote:
>> > Sybren Stuvel <[EMAIL PROTECTED]> writes:
>> >> Because of "there should only be one way to do it, and that way should
>> >> be obvious". There are already the str.join and unicode.join methods,
>> >
>> > Those are obvious???
>>
>>
Georg Brandl wrote:
> Paul Rubin wrote:
> > Sybren Stuvel <[EMAIL PROTECTED]> writes:
> >> Because of "there should only be one way to do it, and that way should
> >> be obvious". There are already the str.join and unicode.join methods,
> >
> > Those are obvious???
>
> Why would you try to sum up
Paul Rubin wrote:
> Georg Brandl <[EMAIL PROTECTED]> writes:
>> Why would you try to sum up strings? Besides, the ''.join idiom is quite
>> common in Python.
>
> Just because it's common doesn't mean it's obvious. In my opinion
> it's as ugly as sin, and the fact that it's an idiom shows a
> shor
"Paddy" <[EMAIL PROTECTED]> writes:
> I also found this from Guido:
> http://mail.python.org/pipermail/python-dev/2003-April/034853.html
> And this, in the same thread:
> http://mail.python.org/pipermail/python-dev/2003-April/034854.html
>
> So,
> The upshot is that complexity matters. The alg
Paul Rubin wrote:
> "Paddy" <[EMAIL PROTECTED]> writes:
> > Pythons designers seem to know and apply the advantages of having fewer
> > 'themes' that can be applied with less constraints I am curious about
> > such a constraint on sum.
>
> The opposing argument is that sum is sort of like reduce,
"Paddy" <[EMAIL PROTECTED]> writes:
> Pythons designers seem to know and apply the advantages of having fewer
> 'themes' that can be applied with less constraints I am curious about
> such a constraint on sum.
The opposing argument is that sum is sort of like reduce, i.e.
sum((a,b,c,d)) could conc
Sybren Stuvel <[EMAIL PROTECTED]> writes:
> > Those are obvious???
> Yup. Just read the string documentation and you're off.
Huh? Just because some obscure weirdness like this is in the manual,
doesn't make it obvious or natural.
--
http://mail.python.org/mailman/listinfo/python-list
Georg Brandl wrote:
> Paddy wrote:
<>
> > I get where you are coming from, but in this case we have a function,
> > sum, that is not as geeral as it could be. sum is already here, and
> > works for some types but not for strings which seems an arbitrary
> > limitation that impede duck typing.
>
>
Georg Brandl <[EMAIL PROTECTED]> writes:
> Why would you try to sum up strings? Besides, the ''.join idiom is quite
> common in Python.
Just because it's common doesn't mean it's obvious. In my opinion
it's as ugly as sin, and the fact that it's an idiom shows a
shortcoming in Python. The obviou
Fredrik Lundh wrote:
> Paddy wrote:
>
> > Here is where I see the break in the 'flow':
> >
> 1+2+3
> > 6
> sum([1,2,3], 0)
> > 6
> [1] + [2] +[3]
> > [1, 2, 3]
> sum([[1],[2],[3]], [])
> > [1, 2, 3]
> '1' + '2' + '3'
> > '123'
> sum(['1','2','3'], '')
> > Traceback (m
Paddy wrote:
> Here is where I see the break in the 'flow':
>
1+2+3
> 6
sum([1,2,3], 0)
> 6
[1] + [2] +[3]
> [1, 2, 3]
sum([[1],[2],[3]], [])
> [1, 2, 3]
'1' + '2' + '3'
> '123'
sum(['1','2','3'], '')
> Traceback (most recent call last):
> File "", line 1, in ?
> T
Paddy wrote:
> Sybren Stuvel wrote:
>> Paddy enlightened us with:
>> > Well, after all the above, there is a question:
>> >
>> > Why not make sum work for strings too?
>>
>> Because of "there should only be one way to do it, and that way should
>> be obvious". There are already the str.join and u
Sybren Stuvel wrote:
> Paddy enlightened us with:
> > Well, after all the above, there is a question:
> >
> > Why not make sum work for strings too?
>
> Because of "there should only be one way to do it, and that way should
> be obvious". There are already the str.join and unicode.join methods,
Sybren Stuvel wrote:
> Paddy enlightened us with:
> > Well, after all the above, there is a question:
> >
> > Why not make sum work for strings too?
>
> Because of "there should only be one way to do it, and that way should
> be obvious". There are already the str.join and unicode.join methods,
>
[EMAIL PROTECTED] wrote:
> Paul Rubin:
>
>>Sybren Stuvel:
>>
>>>Because of "there should only be one way to do it, and that way should
>>>be obvious". There are already the str.join and unicode.join methods,
>>
>>Those are obvious???
>
>
> They aren't fully obvious (because they are methods of t
Paul Rubin:
> Sybren Stuvel:
> > Because of "there should only be one way to do it, and that way should
> > be obvious". There are already the str.join and unicode.join methods,
>
> Those are obvious???
They aren't fully obvious (because they are methods of the separator
string), but after reading
Paul Rubin wrote:
> Sybren Stuvel <[EMAIL PROTECTED]> writes:
>> Because of "there should only be one way to do it, and that way should
>> be obvious". There are already the str.join and unicode.join methods,
>
> Those are obvious???
Why would you try to sum up strings? Besides, the ''.join idio
Sybren Stuvel <[EMAIL PROTECTED]> writes:
> Because of "there should only be one way to do it, and that way should
> be obvious". There are already the str.join and unicode.join methods,
Those are obvious???
--
http://mail.python.org/mailman/listinfo/python-list
Sybren Stuvel wrote:
>> Why not make sum work for strings too?
>
> Because of "there should only be one way to do it, and that way should
> be obvious".
I would have thought that "performance" and "proper use of English" was
more relevant, though.
--
http://mail.python.org/mailman/listin
52 matches
Mail list logo
