Raymond Hettinger added the comment:
Guido, do you care to close this one?
Terry, has channeled you and thinks it may be against your wishes to turn sum()
into a general purpose sequence concatenator. I also seem to recall you
expresses similar thoughts back when Alex Martelli first
Guido van Rossum added the comment:
The example code is a perversion and should not be encouraged.
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
Terry J. Reedy added the comment:
Sergey, please stop calling the current documented behavior a bug.
https://docs.python.org/3/library/functions.html#sum says 'The iterable‘s items
are normally numbers ... To concatenate a series of iterables, consider using
itertools.chain().
To make a
Serhiy Storchaka added the comment:
On the contrary, it will reduce memory usage and creation time compared to
regular tuples, because in cases like:
c = a + b
you do not have to spend time and memory for allocating and copying elements
of a.
This is not a common case. A common case is
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
___
___
Python-bugs-list
Sergey added the comment:
This is not a common case. A common case is creating short tuples and keeping
a lot of tuples in memory.
For fast += you need keep not only a size of tuple, but also a size of
allocated memory. It's a cause of sys.getsizeof([1, 2]) sys.getsizeof((1,
2)).
Sergey added the comment:
Attached fasttuple.py is a Proof-of-Concept implementation of tuple, that
reuses same data storage when possible. Its possible usage looks similar to
built-in tuples:
from fasttuple import ft
a = ft([1,2])
b = a + ft([3,4])
c = b + ft([5,6])
d = b +
Serhiy Storchaka added the comment:
I guess such implementation of tuple will increase memory usage and creation
time which are critical important for tuples.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
Sergey added the comment:
I guess such implementation of tuple will increase memory usage
and creation time which are critical important for tuples.
On the contrary, it will reduce memory usage and creation time compared to
regular tuples, because in cases like:
c = a + b
you do not have
Sergey added the comment:
This optimisation is a semantic change. It breaks backward
compatibility in cases where a = a + b and a += b do not result
in the name a having the same value. In particular this breaks
backward compatibility for numpy users.
I didn't knew that. Then I guess
Oscar Benjamin added the comment:
This optimisation is a semantic change. It breaks backward compatibility in
cases where a = a + b and a += b do not result in the name a having the same
value. In particular this breaks backward compatibility for numpy users.
Numpy arrays treat += differently
Ethan Furman added the comment:
So making this a speed-up for generic objects using __iadd__ is out.
The only question remaining is: is it worth special casing a few specific
objects (list, tuple, str) to optimise performance?
The str question has already been answered: it's special cased to
Sergey added the comment:
Steven D'Aprano noticed that there's an obscure case of:
class A(list):
... def __add__(self, other):
... return A(super(A,self).__add__(other))
... def __radd__(self, other):
... return A(other) + self
...
Where:
type( [1] + A([2]) )
class
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
___
___
Python-bugs-list
Sergey added the comment:
This patch implements another solution to the same bug. But instead of changing
default code it adds a special case optimization for lists, tuples and strings,
similar to those two special cases for numbers, that are already there.
=== Lists ===
No patch:
$
Ramchandra Apte added the comment:
I agree with Sergey. Would be nice if it could use copy.copy (though that might
change behaviour a bit)
--
nosy: +Ramchandra Apte
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
Sergey added the comment:
I don't know about IronPython, but Jython and PyPy have same behavior as
CPython.
Right. I was wrong, at least Jython and PyPy suffer from this bug too.
I think that it is worthwhile to discuss the idea at first in the
Python-Ideas mailing list [1].
Ok, wrote
Serhiy Storchaka added the comment:
Looks like this bug is CPython-specific, others (Jython, IronPython...) don't
have it, so people will move code that depends on the internal optimization
to other pythons that DO have it. :)
I don't know about IronPython, but Jython and PyPy have same
Terry J. Reedy added the comment:
Performance enhancements do not normally go in bugfix releases. The issue of
quadratic performance of sum(sequences, null_seq) is known, which is why the
doc says that sum() is for numbers and recommends .join for strings and
itertools.chain for other
Serhiy Storchaka added the comment:
I agree with Terry. CPython deliberately disallow use sum() with lists of
strings.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
___
Sergey added the comment:
The issue of quadratic performance of sum(sequences, null_seq) is known
I hope it's never too late to fix some bugs... :)
sum([[1,2,3]]*n, []) == [1,2,3]*n == list(chain.from_iterable([[1,2,3]]*n))
But if you already have a list of lists, and you need to join the
New submission from Sergey:
Problem
===
Code:
sum([[1,2,3]]*100, [])
takes forever to complete.
Suggestion
==
Patch sum() function so that it did not created 100 copies of result, but
created just one. Attached patch does that.
Before patch:
$ ./python -mtimeit
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
___
___
Python-bugs-list mailing list
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18305
___
___
24 matches
Mail list logo
