INADA Naoki added the comment:
> Fixed fromkeys() in Py2.7. Stills needs to be forward ported to 3.4/3.5.
dict.fromkeys() is fixed already in 3.6+.
dict(l) doesn't presize the dict. If it's desirable, let's create a new issue.
--
nosy: +inada.naoki
resolution: -> fixed
status: open
Raymond Hettinger added the comment:
Fixed fromkeys() in Py2.7. Stills needs to be forward ported to 3.4/3.5.
--
assignee: rhettinger -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23971
Roundup Robot added the comment:
New changeset cd0706499812 by Raymond Hettinger in branch '2.7':
Issue #23971: Fix underestimated presizing in dict.fromkeys()
https://hg.python.org/cpython/rev/cd0706499812
--
nosy: +python-dev
___
Python tracker
Serhiy Storchaka added the comment:
An example of uncollectable loop if tp_clear is not implemented:
class A:
@property
def f(self): pass
A.f.__doc__ = (A.f,)
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
Changes by Serhiy Storchaka storch...@gmail.com:
--
Removed message: http://bugs.python.org/msg243078
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23971
___
Serhiy Storchaka added the comment:
-if (dictresize(mp, Py_SIZE(seq))) {
+if (dictresize(mp, Py_SIZE(seq) / 2 * 3)) {
If Py_SIZE(seq) is 1, dictresize argument is 0.
Why not wryte the expression as Py_SIZE(seq) * 3 / 2? It never overflows,
because Py_SIZE(seq) is the
Mark Dickinson added the comment:
From the patch:
-if (dictresize(mp, Py_SIZE(seq))) {
+if (dictresize(mp, Py_SIZE(seq) / 2 * 3)) {
Isn't there a risk of signed overflow here? The dictresize function has an
`assert(minused = 0)`, which is going to fail for values of
Mark Dickinson added the comment:
It never overflows, because Py_SIZE(seq) is the size of allocated array of
pointers.
Ah, good point.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23971
Serhiy Storchaka added the comment:
No, I just asking. If the minimum dict size is 8 and there is no special case
for empty dicts, all is good to me.
But note, that x / 2 * 3 overflows as well as x * 3 / 2.
--
___
Python tracker
Raymond Hettinger added the comment:
If Py_SIZE(seq) is 1, dictresize argument is 0.
That doesn't matter. The minimum dict size is 8.
Why not write Py_SIZE(seq) * 3 / 2?
Because I prefer the / 2 * 3 style so I don't have to think about whether seq
can overflow. Do you really feel like
Gregory P. Smith added the comment:
fwiw, as for 2.7 i personally don't think I would change its behavior around
this at this point. make sure 3.5+ do something desirable. (my link to
dictobject.c above is from 2.7)
--
___
Python tracker
Gregory P. Smith added the comment:
Won't we always consume the memory thanks to a memset(newtable, 0, ...)
https://hg.python.org/cpython/file/df28044b7e14/Objects/dictobject.c#l654 ?
(also, i'm not sure if Windows is allocates mapped pages on demand as posix
systems tend to)
--
Matt Mackall added the comment:
We already presize the output dict and have for ages. The question here is what
size to use. In the current state, we use twice as much memory and CPU as
necessary quite often because we end up spilling and growing... even though we
apparently intentionally
Josh Rosenberg added the comment:
You shouldn't presize when the input is a potentially non-unique iterable. It
makes sense to presize for inputs of type dict or set, but for a list, the
assumption is that many duplicates will be present, since deduping is a common
use case for dicts (less so
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +rhettinger
type: behavior - performance
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23971
___
New submission from Larry Hastings:
Matt Mackall brought this over to me today.
If list l has one million pairs and you do
dict(l)
it creates the dict, then resizes it to a million elements, then starts adding
name/value pairs. But since it's sized to a million elements, it gets beyond
its
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23971
___
___
17 matches
Mail list logo
