mirrors/cpython
0
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2024-11-26 11:24:40 +08:00
Code Issues Packages Projects Releases Wiki Activity
aee0bfedcc
cpython/Objects/dictobject.c

1932 lines
48 KiB
C
Raw Normal View History

Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
Vladimir Marangozov contributed updated comments.
1999-03-25 03:06:42 +08:00
/* Dictionary object implementation using a hash table */
* Changed all copyright messages to include 1993. * Stubs for faster implementation of local variables (not yet finished) * Added function name to code object. Print it for code and function objects. THIS MAKES THE .PYC FILE FORMAT INCOMPATIBLE (the version number has changed accordingly) * Print address of self for built-in methods * New internal functions getattro and setattro (getattr/setattr with string object arg) * Replaced "dictobject" with more powerful "mappingobject" * New per-type functio tp_hash to implement arbitrary object hashing, and hashobject() to interface to it * Added built-in functions hash(v) and hasattr(v, 'name') * classobject: made some functions static that accidentally weren't; added __hash__ special instance method to implement hash() * Added proper comparison for built-in methods and functions
1993-03-29 18:43:31 +08:00
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
#include "Python.h"
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
typedef PyDictEntry dictentry;
typedef PyDictObject dictobject;
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
/* Define this out if you don't want conversion statistics on exit. */
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
#undef SHOW_CONVERSION_COUNTS
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
/* See large comment block below. This must be >= 1. */
#define PERTURB_SHIFT 5
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
/*
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
Major subtleties ahead: Most hash schemes depend on having a "good" hash
function, in the sense of simulating randomness. Python doesn't: its most
important hash functions (for strings and ints) are very regular in common
cases:
>>> map(hash, (0, 1, 2, 3))
[0, 1, 2, 3]
>>> map(hash, ("namea", "nameb", "namec", "named"))
[-1658398457, -1658398460, -1658398459, -1658398462]
>>>
This isn't necessarily bad! To the contrary, in a table of size 2**i, taking
the low-order i bits as the initial table index is extremely fast, and there
are no collisions at all for dicts indexed by a contiguous range of ints.
The same is approximately true when keys are "consecutive" strings. So this
gives better-than-random behavior in common cases, and that's very desirable.
OTOH, when collisions occur, the tendency to fill contiguous slices of the
hash table makes a good collision resolution strategy crucial. Taking only
the last i bits of the hash code is also vulnerable: for example, consider
[i << 16 for i in range(20000)] as a set of keys. Since ints are their own
hash codes, and this fits in a dict of size 2**15, the last 15 bits of every
hash code are all 0: they *all* map to the same table index.
But catering to unusual cases should not slow the usual ones, so we just take
the last i bits anyway. It's up to collision resolution to do the rest. If
we *usually* find the key we're looking for on the first try (and, it turns
out, we usually do -- the table load factor is kept under 2/3, so the odds
are solidly in our favor), then it makes best sense to keep the initial index
computation dirt cheap.
The first half of collision resolution is to visit table indices via this
recurrence:
j = ((5*j) + 1) mod 2**i
For any initial j in range(2**i), repeating that 2**i times generates each
int in range(2**i) exactly once (see any text on random-number generation for
proof). By itself, this doesn't help much: like linear probing (setting
j += 1, or j -= 1, on each loop trip), it scans the table entries in a fixed
order. This would be bad, except that's not the only thing we do, and it's
actually *good* in the common cases where hash keys are consecutive. In an
example that's really too small to make this entirely clear, for a table of
size 2**3 the order of indices is:
0 -> 1 -> 6 -> 7 -> 4 -> 5 -> 2 -> 3 -> 0 [and here it's repeating]
If two things come in at index 5, the first place we look after is index 2,
not 6, so if another comes in at index 6 the collision at 5 didn't hurt it.
Linear probing is deadly in this case because there the fixed probe order
is the *same* as the order consecutive keys are likely to arrive. But it's
extremely unlikely hash codes will follow a 5*j+1 recurrence by accident,
and certain that consecutive hash codes do not.
The other half of the strategy is to get the other bits of the hash code
into play. This is done by initializing a (unsigned) vrbl "perturb" to the
full hash code, and changing the recurrence to:
j = (5*j) + 1 + perturb;
perturb >>= PERTURB_SHIFT;
use j % 2**i as the next table index;
Now the probe sequence depends (eventually) on every bit in the hash code,
and the pseudo-scrambling property of recurring on 5*j+1 is more valuable,
because it quickly magnifies small differences in the bits that didn't affect
the initial index. Note that because perturb is unsigned, if the recurrence
is executed often enough perturb eventually becomes and remains 0. At that
point (very rarely reached) the recurrence is on (just) 5*j+1 again, and
that's certain to find an empty slot eventually (since it generates every int
in range(2**i), and we make sure there's always at least one empty slot).
Selecting a good value for PERTURB_SHIFT is a balancing act. You want it
small so that the high bits of the hash code continue to affect the probe
sequence across iterations; but you want it large so that in really bad cases
the high-order hash bits have an effect on early iterations. 5 was "the
best" in minimizing total collisions across experiments Tim Peters ran (on
both normal and pathological cases), but 4 and 6 weren't significantly worse.
Historical: Reimer Behrends contributed the idea of using a polynomial-based
approach, using repeated multiplication by x in GF(2**n) where an irreducible
polynomial for each table size was chosen such that x was a primitive root.
Christian Tismer later extended that to use division by x instead, as an
efficient way to get the high bits of the hash code into play. This scheme
also gave excellent collision statistics, but was more expensive: two
if-tests were required inside the loop; computing "the next" index took about
the same number of operations but without as much potential parallelism
(e.g., computing 5*j can go on at the same time as computing 1+perturb in the
above, and then shifting perturb can be done while the table index is being
masked); and the dictobject struct required a member to hold the table's
polynomial. In Tim's experiments the current scheme ran faster, produced
equally good collision statistics, needed less code & used less memory.
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
*/
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
/* Object used as dummy key to fill deleted entries */
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
static PyObject *dummy; /* Initialized by first call to newdictobject() */
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
/* forward declarations */
static dictentry *
lookdict_string(dictobject *mp, PyObject *key, long hash);
#ifdef SHOW_CONVERSION_COUNTS
static long created = 0L;
static long converted = 0L;
static void
show_counts(void)
{
fprintf(stderr, "created %ld string dicts\n", created);
fprintf(stderr, "converted %ld to normal dicts\n", converted);
fprintf(stderr, "%.2f%% conversion rate\n", (100.0*converted)/created);
}
#endif
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
/* Initialization macros.
There are two ways to create a dict: PyDict_New() is the main C API
function, and the tp_new slot maps to dict_new(). In the latter case we
can save a little time over what PyDict_New does because it's guaranteed
that the PyDictObject struct is already zeroed out.
Everyone except dict_new() should use EMPTY_TO_MINSIZE (unless they have
an excellent reason not to).
*/
#define INIT_NONZERO_DICT_SLOTS(mp) do { \
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
(mp)->ma_table = (mp)->ma_smalltable; \
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
(mp)->ma_mask = PyDict_MINSIZE - 1; \
} while(0)
#define EMPTY_TO_MINSIZE(mp) do { \
memset((mp)->ma_smalltable, 0, sizeof((mp)->ma_smalltable)); \
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
(mp)->ma_used = (mp)->ma_fill = 0; \
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
INIT_NONZERO_DICT_SLOTS(mp); \
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
} while(0)
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *
Miscelaneous ANSIfications. I'm assuming here 'main' should take (int, char**) and return an int even on PC platforms. If not, please fix PC/utils/makesrc.c ;-P
2000-07-23 03:25:51 +08:00
PyDict_New(void)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictobject *mp;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (dummy == NULL) { /* Auto-initialize dummy */
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
dummy = PyString_FromString("<dummy key>");
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (dummy == NULL)
return NULL;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
#ifdef SHOW_CONVERSION_COUNTS
Py_AtExit(show_counts);
#endif
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Use new GC API.
2001-08-30 07:54:21 +08:00
mp = PyObject_GC_New(dictobject, &PyDict_Type);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (mp == NULL)
return NULL;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
EMPTY_TO_MINSIZE(mp);
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
mp->ma_lookup = lookdict_string;
#ifdef SHOW_CONVERSION_COUNTS
++created;
#endif
Use new GC API.
2001-08-30 07:54:21 +08:00
_PyObject_GC_TRACK(mp);
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
return (PyObject *)mp;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
/*
The basic lookup function used by all operations.
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
This is based on Algorithm D from Knuth Vol. 3, Sec. 6.4.
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
Open addressing is preferred over chaining since the link overhead for
chaining would be substantial (100% with typical malloc overhead).
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
The initial probe index is computed as hash mod the table size. Subsequent
probe indices are computed as explained earlier.
Vladimir Marangozov contributed updated comments.
1999-03-25 03:06:42 +08:00
All arithmetic on hash should ignore overflow.
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
(The details in this version are due to Tim Peters, building on many past
contributions by Reimer Behrends, Jyrki Alakuijala, Vladimir Marangozov and
Christian Tismer).
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
This function must never return NULL; failures are indicated by returning
a dictentry* for which the me_value field is NULL. Exceptions are never
reported by this function, and outstanding exceptions are maintained.
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
*/
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
static dictentry *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
lookdict(dictobject *mp, PyObject *key, register long hash)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
register int i;
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
register unsigned int perturb;
Made lookdict nearly twice as fast, resulting in a 5% overall improvement of pystone. Vladimir Marangozov.
1997-08-19 05:52:47 +08:00
register dictentry *freeslot;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
register unsigned int mask = mp->ma_mask;
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
dictentry *ep0 = mp->ma_table;
register dictentry *ep;
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
register int restore_error;
register int checked_error;
Clear errors raised by PyObject_Compare() without losing any existing exception context. This avoids improperly propogating errors raised by a user-defined __cmp__() by a subsequent lookup operation. This patch does *not* include the performance enhancement patch for dictionaries with string keys only; that will be checked in separately. This closes SourceForge patch #101277 and bug #112558.
2000-09-01 03:04:07 +08:00
register int cmp;
PyObject *err_type, *err_value, *err_tb;
lookdict: stop more insane core-dump mutating comparison cases. Should be possible to provoke unbounded recursion now, but leaving that to someone else to provoke and repair. Bugfix candidate -- although this is getting harder to backstitch, and the cases it's protecting against are mondo contrived.
2001-06-03 12:54:32 +08:00
PyObject *startkey;
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask". The comment following used to say: /* We use ~hash instead of hash, as degenerate hash functions, such as for ints <sigh>, can have lots of leading zeros. It's not really a performance risk, but better safe than sorry. 12-Dec-00 tim: so ~hash produces lots of leading ones instead -- what's the gain? */ That is, there was never a good reason for doing it. And to the contrary, as explained on Python-Dev last December, it tended to make the *sum* (i + incr) & mask (which is the first table index examined in case of collison) the same "too often" across distinct hashes. Changing to the simpler "i = hash & mask" reduced the number of string-dict collisions (== # number of times we go around the lookup for-loop) from about 6 million to 5 million during a full run of the test suite (these are approximate because the test suite does some random stuff from run to run). The number of collisions in non-string dicts also decreased, but not as dramatically. Note that this may, for a given dict, change the order (wrt previous releases) of entries exposed by .keys(), .values() and .items(). A number of std tests suffered bogus failures as a result. For dicts keyed by small ints, or (less so) by characters, the order is much more likely to be in increasing order of key now; e.g., >>> d = {} >>> for i in range(10): ... d[i] = i ... >>> d {0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} >>> Unfortunately. people may latch on to that in small examples and draw a bogus conclusion. test_support.py Moved test_extcall's sortdict() into test_support, made it stronger, and imported sortdict into other std tests that needed it. test_unicode.py Excluced cp875 from the "roundtrip over range(128)" test, because cp875 doesn't have a well-defined inverse for unicode("?", "cp875"). See Python-Dev for excruciating details. Cookie.py Chaged various output functions to sort dicts before building strings from them. test_extcall Fiddled the expected-result file. This remains sensitive to native dict ordering, because, e.g., if there are multiple errors in a keyword-arg dict (and test_extcall sets up many cases like that), the specific error Python complains about first depends on native dict ordering.
2001-05-13 08:19:31 +08:00
i = hash & mask;
Small lookmapping nits: - remove bogus initialization using uninitialized i - derive initial incr from hash - copy mp->ma_table into a local variable
1997-01-29 23:53:56 +08:00
ep = &ep0[i];
Slight rearrangement of code in lookdict() by Vladimir Marangozov, to make a common case slightly faster.
1998-10-07 00:01:14 +08:00
if (ep->me_key == NULL || ep->me_key == key)
Rewrote lookmapping() according to suggestions by Jyrki Alakuijala.
1997-01-17 05:06:45 +08:00
return ep;
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
restore_error = checked_error = 0;
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
if (ep->me_key == dummy)
Rewrote lookmapping() according to suggestions by Jyrki Alakuijala.
1997-01-17 05:06:45 +08:00
freeslot = ep;
Made lookdict nearly twice as fast, resulting in a 5% overall improvement of pystone. Vladimir Marangozov.
1997-08-19 05:52:47 +08:00
else {
Clear errors raised by PyObject_Compare() without losing any existing exception context. This avoids improperly propogating errors raised by a user-defined __cmp__() by a subsequent lookup operation. This patch does *not* include the performance enhancement patch for dictionaries with string keys only; that will be checked in separately. This closes SourceForge patch #101277 and bug #112558.
2000-09-01 03:04:07 +08:00
if (ep->me_hash == hash) {
/* error can't have been checked yet */
checked_error = 1;
if (PyErr_Occurred()) {
restore_error = 1;
PyErr_Fetch(&err_type, &err_value, &err_tb);
}
lookdict: stop more insane core-dump mutating comparison cases. Should be possible to provoke unbounded recursion now, but leaving that to someone else to provoke and repair. Bugfix candidate -- although this is getting harder to backstitch, and the cases it's protecting against are mondo contrived.
2001-06-03 12:54:32 +08:00
startkey = ep->me_key;
cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
if (cmp < 0)
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
PyErr_Clear();
lookdict: stop more insane core-dump mutating comparison cases. Should be possible to provoke unbounded recursion now, but leaving that to someone else to provoke and repair. Bugfix candidate -- although this is getting harder to backstitch, and the cases it's protecting against are mondo contrived.
2001-06-03 12:54:32 +08:00
if (ep0 == mp->ma_table && ep->me_key == startkey) {
if (cmp > 0)
goto Done;
}
else {
/* The compare did major nasty stuff to the
* dict: start over.
* XXX A clever adversary could prevent this
* XXX from terminating.
*/
ep = lookdict(mp, key, hash);
goto Done;
}
Made lookdict nearly twice as fast, resulting in a 5% overall improvement of pystone. Vladimir Marangozov.
1997-08-19 05:52:47 +08:00
}
freeslot = NULL;
String interning.
1997-01-18 15:55:05 +08:00
}
Implement an old idea of Christian Tismer's: use polynomial division instead of multiplication to generate the probe sequence. The idea is recorded in Python-Dev for Dec 2000, but that version is prone to rare infinite loops. The value is in getting *all* the bits of the hash code to participate; and, e.g., this speeds up querying every key in a dict with keys [i << 16 for i in range(20000)] by a factor of 500. Should be equally valuable in any bad case where the high-order hash bits were getting ignored. Also wrote up some of the motivations behind Python's ever-more-subtle hash table strategy.
2001-05-27 15:39:22 +08:00
Aggressive reordering of dict comparisons. In case of collision, it stands to reason that me_key is much more likely to match the key we're looking for than to match dummy, and if the key is absent me_key is much more likely to be NULL than dummy: most dicts don't even have a dummy entry. Running instrumented dict code over the test suite and some apps confirmed that matching dummy was 200-300x less frequent than matching key in practice. So this reorders the tests to try the common case first. It can lose if a large dict with many collisions is mostly deleted, not resized, and then frequently searched, but that's hardly a case we should be favoring.
2001-05-13 14:43:53 +08:00
/* In the loop, me_key == dummy is by far (factor of 100s) the
least likely outcome, so test for that last. */
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
for (perturb = hash; ; perturb >>= PERTURB_SHIFT) {
i = (i << 2) + i + perturb + 1;
ep = &ep0[i & mask];
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
if (ep->me_key == NULL) {
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
if (freeslot != NULL)
ep = freeslot;
break;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
}
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
if (ep->me_key == key)
break;
if (ep->me_hash == hash && ep->me_key != dummy) {
Clear errors raised by PyObject_Compare() without losing any existing exception context. This avoids improperly propogating errors raised by a user-defined __cmp__() by a subsequent lookup operation. This patch does *not* include the performance enhancement patch for dictionaries with string keys only; that will be checked in separately. This closes SourceForge patch #101277 and bug #112558.
2000-09-01 03:04:07 +08:00
if (!checked_error) {
checked_error = 1;
if (PyErr_Occurred()) {
restore_error = 1;
PyErr_Fetch(&err_type, &err_value,
&err_tb);
}
}
lookdict: stop more insane core-dump mutating comparison cases. Should be possible to provoke unbounded recursion now, but leaving that to someone else to provoke and repair. Bugfix candidate -- although this is getting harder to backstitch, and the cases it's protecting against are mondo contrived.
2001-06-03 12:54:32 +08:00
startkey = ep->me_key;
cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
if (cmp < 0)
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
PyErr_Clear();
lookdict: stop more insane core-dump mutating comparison cases. Should be possible to provoke unbounded recursion now, but leaving that to someone else to provoke and repair. Bugfix candidate -- although this is getting harder to backstitch, and the cases it's protecting against are mondo contrived.
2001-06-03 12:54:32 +08:00
if (ep0 == mp->ma_table && ep->me_key == startkey) {
if (cmp > 0)
break;
}
else {
/* The compare did major nasty stuff to the
* dict: start over.
* XXX A clever adversary could prevent this
* XXX from terminating.
*/
ep = lookdict(mp, key, hash);
break;
}
Changed the lookup algorithm again, based on Reimer Behrends's post. The table size is now constrained to be a power of two, and we use a variable increment based on GF(2^n)-{0} (not that I have the faintest idea what that is :-) which helps avoid the expensive '%' operation. Some of the entries in the table of polynomials have been modified according to a post by Tim Peters.
1997-01-28 08:00:11 +08:00
}
Aggressive reordering of dict comparisons. In case of collision, it stands to reason that me_key is much more likely to match the key we're looking for than to match dummy, and if the key is absent me_key is much more likely to be NULL than dummy: most dicts don't even have a dummy entry. Running instrumented dict code over the test suite and some apps confirmed that matching dummy was 200-300x less frequent than matching key in practice. So this reorders the tests to try the common case first. It can lose if a large dict with many collisions is mostly deleted, not resized, and then frequently searched, but that's hardly a case we should be favoring.
2001-05-13 14:43:53 +08:00
else if (ep->me_key == dummy && freeslot == NULL)
freeslot = ep;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
lookdict: Reduce obfuscating code duplication with a judicious goto. This code is likely to get even hairier to squash core dumps due to mutating comparisons, and it's hard enough to follow without that.
2001-06-03 12:14:43 +08:00
Done:
if (restore_error)
PyErr_Restore(err_type, err_value, err_tb);
return ep;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
/*
* Hacked up version of lookdict which can assume keys are always strings;
* this assumption allows testing for errors during PyObject_Compare() to
* be dropped; string-string comparisons never raise exceptions. This also
* means we don't need to go through PyObject_Compare(); we can always use
Patch #424335: Implement string_richcompare, remove string_compare. Use new _PyString_Eq in lookdict_string.
2001-05-25 00:56:35 +08:00
* _PyString_Eq directly.
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
*
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
* This is valuable because the general-case error handling in lookdict() is
* expensive, and dicts with pure-string keys are very common.
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
*/
static dictentry *
lookdict_string(dictobject *mp, PyObject *key, register long hash)
{
register int i;
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
register unsigned int perturb;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
register dictentry *freeslot;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
register unsigned int mask = mp->ma_mask;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
dictentry *ep0 = mp->ma_table;
register dictentry *ep;
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
/* Make sure this function doesn't have to handle non-string keys,
including subclasses of str; e.g., one reason to subclass
strings is to override __eq__, and for speed we don't cater to
that here. */
if (!PyString_CheckExact(key)) {
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
#ifdef SHOW_CONVERSION_COUNTS
++converted;
#endif
mp->ma_lookup = lookdict;
return lookdict(mp, key, hash);
}
Get rid of the superstitious "~" in dict hashing's "i = (~hash) & mask". The comment following used to say: /* We use ~hash instead of hash, as degenerate hash functions, such as for ints <sigh>, can have lots of leading zeros. It's not really a performance risk, but better safe than sorry. 12-Dec-00 tim: so ~hash produces lots of leading ones instead -- what's the gain? */ That is, there was never a good reason for doing it. And to the contrary, as explained on Python-Dev last December, it tended to make the *sum* (i + incr) & mask (which is the first table index examined in case of collison) the same "too often" across distinct hashes. Changing to the simpler "i = hash & mask" reduced the number of string-dict collisions (== # number of times we go around the lookup for-loop) from about 6 million to 5 million during a full run of the test suite (these are approximate because the test suite does some random stuff from run to run). The number of collisions in non-string dicts also decreased, but not as dramatically. Note that this may, for a given dict, change the order (wrt previous releases) of entries exposed by .keys(), .values() and .items(). A number of std tests suffered bogus failures as a result. For dicts keyed by small ints, or (less so) by characters, the order is much more likely to be in increasing order of key now; e.g., >>> d = {} >>> for i in range(10): ... d[i] = i ... >>> d {0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} >>> Unfortunately. people may latch on to that in small examples and draw a bogus conclusion. test_support.py Moved test_extcall's sortdict() into test_support, made it stronger, and imported sortdict into other std tests that needed it. test_unicode.py Excluced cp875 from the "roundtrip over range(128)" test, because cp875 doesn't have a well-defined inverse for unicode("?", "cp875"). See Python-Dev for excruciating details. Cookie.py Chaged various output functions to sort dicts before building strings from them. test_extcall Fiddled the expected-result file. This remains sensitive to native dict ordering, because, e.g., if there are multiple errors in a keyword-arg dict (and test_extcall sets up many cases like that), the specific error Python complains about first depends on native dict ordering.
2001-05-13 08:19:31 +08:00
i = hash & mask;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
ep = &ep0[i];
if (ep->me_key == NULL || ep->me_key == key)
return ep;
if (ep->me_key == dummy)
freeslot = ep;
else {
if (ep->me_hash == hash
Patch #424335: Implement string_richcompare, remove string_compare. Use new _PyString_Eq in lookdict_string.
2001-05-25 00:56:35 +08:00
&& _PyString_Eq(ep->me_key, key)) {
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
return ep;
}
freeslot = NULL;
}
Implement an old idea of Christian Tismer's: use polynomial division instead of multiplication to generate the probe sequence. The idea is recorded in Python-Dev for Dec 2000, but that version is prone to rare infinite loops. The value is in getting *all* the bits of the hash code to participate; and, e.g., this speeds up querying every key in a dict with keys [i << 16 for i in range(20000)] by a factor of 500. Should be equally valuable in any bad case where the high-order hash bits were getting ignored. Also wrote up some of the motivations behind Python's ever-more-subtle hash table strategy.
2001-05-27 15:39:22 +08:00
Aggressive reordering of dict comparisons. In case of collision, it stands to reason that me_key is much more likely to match the key we're looking for than to match dummy, and if the key is absent me_key is much more likely to be NULL than dummy: most dicts don't even have a dummy entry. Running instrumented dict code over the test suite and some apps confirmed that matching dummy was 200-300x less frequent than matching key in practice. So this reorders the tests to try the common case first. It can lose if a large dict with many collisions is mostly deleted, not resized, and then frequently searched, but that's hardly a case we should be favoring.
2001-05-13 14:43:53 +08:00
/* In the loop, me_key == dummy is by far (factor of 100s) the
least likely outcome, so test for that last. */
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
for (perturb = hash; ; perturb >>= PERTURB_SHIFT) {
i = (i << 2) + i + perturb + 1;
ep = &ep0[i & mask];
Aggressive reordering of dict comparisons. In case of collision, it stands to reason that me_key is much more likely to match the key we're looking for than to match dummy, and if the key is absent me_key is much more likely to be NULL than dummy: most dicts don't even have a dummy entry. Running instrumented dict code over the test suite and some apps confirmed that matching dummy was 200-300x less frequent than matching key in practice. So this reorders the tests to try the common case first. It can lose if a large dict with many collisions is mostly deleted, not resized, and then frequently searched, but that's hardly a case we should be favoring.
2001-05-13 14:43:53 +08:00
if (ep->me_key == NULL)
return freeslot == NULL ? ep : freeslot;
if (ep->me_key == key
|| (ep->me_hash == hash
&& ep->me_key != dummy
Patch #424335: Implement string_richcompare, remove string_compare. Use new _PyString_Eq in lookdict_string.
2001-05-25 00:56:35 +08:00
&& _PyString_Eq(ep->me_key, key)))
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
return ep;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
if (ep->me_key == dummy && freeslot == NULL)
Aggressive reordering of dict comparisons. In case of collision, it stands to reason that me_key is much more likely to match the key we're looking for than to match dummy, and if the key is absent me_key is much more likely to be NULL than dummy: most dicts don't even have a dummy entry. Running instrumented dict code over the test suite and some apps confirmed that matching dummy was 200-300x less frequent than matching key in practice. So this reorders the tests to try the common case first. It can lose if a large dict with many collisions is mostly deleted, not resized, and then frequently searched, but that's hardly a case we should be favoring.
2001-05-13 14:43:53 +08:00
freeslot = ep;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
}
}
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
/*
Internal routine to insert a new item into the table.
Used both by the internal resize routine and by the public insert routine.
Eats a reference to key and one to value.
*/
static void
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
insertdict(register dictobject *mp, PyObject *key, long hash, PyObject *value)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *old_value;
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictentry *ep;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
typedef PyDictEntry *(*lookupfunc)(PyDictObject *, PyObject *, long);
assert(mp->ma_lookup != NULL);
ep = mp->ma_lookup(mp, key, hash);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (ep->me_value != NULL) {
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
old_value = ep->me_value;
ep->me_value = value;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_DECREF(old_value); /* which **CAN** re-enter */
Py_DECREF(key);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
else {
if (ep->me_key == NULL)
mp->ma_fill++;
else
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_DECREF(ep->me_key);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
ep->me_key = key;
ep->me_hash = hash;
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
ep->me_value = value;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
mp->ma_used++;
}
}
/*
Restructure the table by allocating a new table and reinserting all
items again. When entries have been deleted, the new table may
actually be smaller than the old one.
*/
static int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dictresize(dictobject *mp, int minused)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
int newsize;
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
dictentry *oldtable, *newtable, *ep;
int i;
int is_oldtable_malloced;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
dictentry small_copy[PyDict_MINSIZE];
Bugfix candidate. Two exceedingly unlikely errors in dictresize(): 1. The loop for finding the new size had an off-by-one error at the end (could over-index the polys[] vector). 2. The polys[] vector ended with a 0, apparently intended as a sentinel value but never used as such; i.e., it was never checked, so 0 could have been used *as* a polynomial. Neither bug could trigger unless a dict grew to 2**30 slots; since that would consume at least 12GB of memory just to hold the dict pointers, I'm betting it's not the cause of the bug Fred's tracking down <wink>.
2001-05-19 15:04:38 +08:00
assert(minused >= 0);
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
/* Find the smallest table size > minused. */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
for (newsize = PyDict_MINSIZE;
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
newsize <= minused && newsize > 0;
newsize <<= 1)
;
if (newsize <= 0) {
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyErr_NoMemory();
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return -1;
}
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
/* Get space for a new table. */
oldtable = mp->ma_table;
assert(oldtable != NULL);
is_oldtable_malloced = oldtable != mp->ma_smalltable;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
if (newsize == PyDict_MINSIZE) {
dictresize(): Rebuild small tables if there are any dummies, not just if they're entirely full. Not a question of correctness, but of temporarily misplaced common sense.
2001-05-25 00:26:40 +08:00
/* A large table is shrinking, or we can't get any smaller. */
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
newtable = mp->ma_smalltable;
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
if (newtable == oldtable) {
dictresize(): Rebuild small tables if there are any dummies, not just if they're entirely full. Not a question of correctness, but of temporarily misplaced common sense.
2001-05-25 00:26:40 +08:00
if (mp->ma_fill == mp->ma_used) {
/* No dummies, so no point doing anything. */
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
return 0;
dictresize(): Rebuild small tables if there are any dummies, not just if they're entirely full. Not a question of correctness, but of temporarily misplaced common sense.
2001-05-25 00:26:40 +08:00
}
/* We're not going to resize it, but rebuild the
table anyway to purge old dummy entries.
Subtle: This is *necessary* if fill==size,
as lookdict needs at least one virgin slot to
terminate failing searches. If fill < size, it's
merely desirable, as dummies slow searches. */
assert(mp->ma_fill > mp->ma_used);
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
memcpy(small_copy, oldtable, sizeof(small_copy));
oldtable = small_copy;
}
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
}
else {
newtable = PyMem_NEW(dictentry, newsize);
if (newtable == NULL) {
PyErr_NoMemory();
return -1;
}
}
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
/* Make the dict empty, using the new table. */
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
assert(newtable != oldtable);
mp->ma_table = newtable;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
mp->ma_mask = newsize - 1;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
memset(newtable, 0, sizeof(dictentry) * newsize);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
mp->ma_used = 0;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
i = mp->ma_fill;
mp->ma_fill = 0;
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
Speed dictresize by collapsing its two passes into one; the reason given in the comments for using two passes was bogus, as the only object that can get decref'ed due to the copy is the dummy key, and decref'ing dummy can't have side effects (for one thing, dummy is immortal! for another, it's a string object, not a potentially dangerous user-defined object).
2001-05-18 06:25:34 +08:00
/* Copy the data over; this is refcount-neutral for active entries;
dummy entries aren't copied over, of course */
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
for (ep = oldtable; i > 0; ep++) {
if (ep->me_value != NULL) { /* active entry */
--i;
Speed dictresize by collapsing its two passes into one; the reason given in the comments for using two passes was bogus, as the only object that can get decref'ed due to the copy is the dummy key, and decref'ing dummy can't have side effects (for one thing, dummy is immortal! for another, it's a string object, not a potentially dangerous user-defined object).
2001-05-18 06:25:34 +08:00
insertdict(mp, ep->me_key, ep->me_hash, ep->me_value);
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
}
Speed dictresize by collapsing its two passes into one; the reason given in the comments for using two passes was bogus, as the only object that can get decref'ed due to the copy is the dummy key, and decref'ing dummy can't have side effects (for one thing, dummy is immortal! for another, it's a string object, not a potentially dangerous user-defined object).
2001-05-18 06:25:34 +08:00
else if (ep->me_key != NULL) { /* dummy entry */
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
--i;
Speed dictresize by collapsing its two passes into one; the reason given in the comments for using two passes was bogus, as the only object that can get decref'ed due to the copy is the dummy key, and decref'ing dummy can't have side effects (for one thing, dummy is immortal! for another, it's a string object, not a potentially dangerous user-defined object).
2001-05-18 06:25:34 +08:00
assert(ep->me_key == dummy);
Py_DECREF(ep->me_key);
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
}
Speed dictresize by collapsing its two passes into one; the reason given in the comments for using two passes was bogus, as the only object that can get decref'ed due to the copy is the dummy key, and decref'ing dummy can't have side effects (for one thing, dummy is immortal! for another, it's a string object, not a potentially dangerous user-defined object).
2001-05-18 06:25:34 +08:00
/* else key == value == NULL: nothing to do */
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
Jack Jansen hit a bug in the new dict code, reported on python-dev. dictresize() was too aggressive about never ever resizing small dicts. If a small dict is entirely full, it needs to rebuild it despite that it won't actually resize it, in order to purge old dummy entries thus creating at least one virgin slot (lookdict assumes at least one such exists). Also took the opportunity to add some high-level comments to dictresize.
2001-05-24 07:33:57 +08:00
if (is_oldtable_malloced)
Vladimir Marangozov's long-awaited malloc restructuring. For more comments, read the patches@python.org archives. For documentation read the comments in mymalloc.h and objimpl.h. (This is not exactly what Vladimir posted to the patches list; I've made a few changes, and Vladimir sent me a fix in private email for a problem that only occurs in debug mode. I'm also holding back on his change to main.c, which seems unnecessary to me.)
2000-05-04 07:44:39 +08:00
PyMem_DEL(oldtable);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return 0;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_GetItem(PyObject *op, PyObject *key)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
long hash;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
dictobject *mp = (dictobject *)op;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (!PyDict_Check(op)) {
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return NULL;
}
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#endif
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = PyObject_Hash(key);
Make sure that PyDict_GetItem[String]() *never* raises an exception. If the argument is not a dictionary, simply return NULL. If the hash() on the key fails, clear the error.
1998-05-14 09:00:51 +08:00
if (hash == -1) {
PyErr_Clear();
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
return NULL;
Make sure that PyDict_GetItem[String]() *never* raises an exception. If the argument is not a dictionary, simply return NULL. If the hash() on the key fails, clear the error.
1998-05-14 09:00:51 +08:00
}
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
}
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
return (mp->ma_lookup)(mp, key, hash)->me_value;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
/* CAUTION: PyDict_SetItem() must guarantee that it won't resize the
* dictionary if it is merely replacing the value for an existing key.
* This is means that it's safe to loop over a dictionary with
* PyDict_Next() and occasionally replace a value -- but you can't
* insert new keys or remove them.
*/
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_SetItem(register PyObject *op, PyObject *key, PyObject *value)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictobject *mp;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
register long hash;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
register int n_used;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (!PyDict_Check(op)) {
PyErr_BadInternalCall();
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return -1;
}
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
mp = (dictobject *)op;
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (PyString_CheckExact(key)) {
String interning.
1997-01-18 15:55:05 +08:00
#ifdef INTERN_STRINGS
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (((PyStringObject *)key)->ob_sinterned != NULL) {
key = ((PyStringObject *)key)->ob_sinterned;
hash = ((PyStringObject *)key)->ob_shash;
String interning.
1997-01-18 15:55:05 +08:00
}
else
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#endif
String interning.
1997-01-18 15:55:05 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = ((PyStringObject *)key)->ob_shash;
String interning.
1997-01-18 15:55:05 +08:00
if (hash == -1)
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = PyObject_Hash(key);
String interning.
1997-01-18 15:55:05 +08:00
}
}
else
#endif
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = PyObject_Hash(key);
String interning.
1997-01-18 15:55:05 +08:00
if (hash == -1)
return -1;
}
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
assert(mp->ma_fill <= mp->ma_mask); /* at least one empty slot */
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
n_used = mp->ma_used;
Py_INCREF(value);
Py_INCREF(key);
insertdict(mp, key, hash, value);
/* If we added a key, we can safely resize. Otherwise skip this!
* If fill >= 2/3 size, adjust size. Normally, this doubles the
Make PyDict_Next safe to use for loops that merely modify the values associated with existing dict keys. This is a variant of part of Michael Hudson's patch #409864 "lazy fix for Pings bizarre scoping crash".
2001-03-22 03:23:56 +08:00
* size, but it's also possible for the dict to shrink (if ma_fill is
* much larger than ma_used, meaning a lot of dict keys have been
* deleted).
*/
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
if (mp->ma_used > n_used && mp->ma_fill*3 >= (mp->ma_mask+1)*2) {
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
if (dictresize(mp, mp->ma_used*2) != 0)
return -1;
}
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return 0;
}
int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_DelItem(PyObject *op, PyObject *key)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictobject *mp;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
register long hash;
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictentry *ep;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *old_value, *old_key;
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (!PyDict_Check(op)) {
PyErr_BadInternalCall();
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return -1;
}
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#endif
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = PyObject_Hash(key);
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
if (hash == -1)
return -1;
}
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
mp = (dictobject *)op;
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
ep = (mp->ma_lookup)(mp, key, hash);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (ep->me_value == NULL) {
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyErr_SetObject(PyExc_KeyError, key);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return -1;
}
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
old_key = ep->me_key;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_INCREF(dummy);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
ep->me_key = dummy;
Lots of minor changes. Note for mappingobject.c: the hash table pointer can now be NULL.
1995-01-03 03:07:15 +08:00
old_value = ep->me_value;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
ep->me_value = NULL;
mp->ma_used--;
Bring comments up to date (e.g., they still said the table had to be a prime size, which is in fact never true anymore ...).
2000-12-13 09:02:46 +08:00
Py_DECREF(old_value);
Py_DECREF(old_key);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return 0;
}
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
void
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Clear(PyObject *op)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
dictobject *mp;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
dictentry *ep, *table;
int table_is_malloced;
int fill;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
dictentry small_copy[PyDict_MINSIZE];
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
#ifdef Py_DEBUG
int i, n;
#endif
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (!PyDict_Check(op))
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
return;
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
mp = (dictobject *)op;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
#ifdef Py_DEBUG
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
n = mp->ma_mask + 1;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
i = 0;
#endif
table = mp->ma_table;
assert(table != NULL);
table_is_malloced = table != mp->ma_smalltable;
/* This is delicate. During the process of clearing the dict,
* decrefs can cause the dict to mutate. To avoid fatal confusion
* (voice of experience), we have to make the dict empty before
* clearing the slots, and never refer to anything via mp->xxx while
* clearing.
*/
fill = mp->ma_fill;
if (table_is_malloced)
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
EMPTY_TO_MINSIZE(mp);
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
else if (fill > 0) {
/* It's a small table with something that needs to be cleared.
* Afraid the only safe way is to copy the dict entries into
* another small table first.
*/
memcpy(small_copy, table, sizeof(small_copy));
table = small_copy;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
EMPTY_TO_MINSIZE(mp);
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
}
/* else it's a small table that's already empty */
/* Now we can finally clear things. If C had refcounts, we could
* assert that the refcount on table is 1 now, i.e. that this function
* has unique access to it, so decref side-effects can't alter it.
*/
for (ep = table; fill > 0; ++ep) {
#ifdef Py_DEBUG
assert(i < n);
++i;
#endif
if (ep->me_key) {
--fill;
Py_DECREF(ep->me_key);
Py_XDECREF(ep->me_value);
}
#ifdef Py_DEBUG
else
assert(ep->me_value == NULL);
#endif
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
if (table_is_malloced)
PyMem_DEL(table);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Make PyDict_Next safe to use for loops that merely modify the values associated with existing dict keys. This is a variant of part of Michael Hudson's patch #409864 "lazy fix for Pings bizarre scoping crash".
2001-03-22 03:23:56 +08:00
/* CAUTION: In general, it isn't safe to use PyDict_Next in a loop that
* mutates the dict. One exception: it is safe if the loop merely changes
* the values associated with the keys (but doesn't insert new keys or
* delete keys), via PyDict_SetItem().
*/
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Next(PyObject *op, int *ppos, PyObject **pkey, PyObject **pvalue)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
int i;
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictobject *mp;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (!PyDict_Check(op))
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
return 0;
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
mp = (dictobject *)op;
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
i = *ppos;
if (i < 0)
return 0;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
while (i <= mp->ma_mask && mp->ma_table[i].me_value == NULL)
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
i++;
*ppos = i+1;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
if (i > mp->ma_mask)
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
return 0;
if (pkey)
*pkey = mp->ma_table[i].me_key;
if (pvalue)
*pvalue = mp->ma_table[i].me_value;
return 1;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
/* Methods */
static void
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_dealloc(register dictobject *mp)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
register dictentry *ep;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
int fill = mp->ma_fill;
Christian Tismer's "trashcan" patch: Added wrapping macros to dictobject.c, listobject.c, tupleobject.c, frameobject.c, traceback.c that safely prevends core dumps on stack overflow. Macros and functions in object.c, object.h. The method is an "elevator destructor" that turns cascading deletes into tail recursive behavior when some limit is hit.
2000-03-14 00:01:29 +08:00
Py_TRASHCAN_SAFE_BEGIN(mp)
Use new GC API.
2001-08-30 07:54:21 +08:00
_PyObject_GC_UNTRACK(mp);
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
for (ep = mp->ma_table; fill > 0; ep++) {
if (ep->me_key) {
--fill;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_DECREF(ep->me_key);
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
Py_XDECREF(ep->me_value);
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
}
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
if (mp->ma_table != mp->ma_smalltable)
Vladimir Marangozov's long-awaited malloc restructuring. For more comments, read the patches@python.org archives. For documentation read the comments in mymalloc.h and objimpl.h. (This is not exactly what Vladimir posted to the patches list; I've made a few changes, and Vladimir sent me a fix in private email for a problem that only occurs in debug mode. I'm also holding back on his change to main.c, which seems unnecessary to me.)
2000-05-04 07:44:39 +08:00
PyMem_DEL(mp->ma_table);
Use new GC API.
2001-08-30 07:54:21 +08:00
PyObject_GC_Del(mp);
Christian Tismer's "trashcan" patch: Added wrapping macros to dictobject.c, listobject.c, tupleobject.c, frameobject.c, traceback.c that safely prevends core dumps on stack overflow. Macros and functions in object.c, object.h. The method is an "elevator destructor" that turns cascading deletes into tail recursive behavior when some limit is hit.
2000-03-14 00:01:29 +08:00
Py_TRASHCAN_SAFE_END(mp)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
static int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_print(register dictobject *mp, register FILE *fp, register int flags)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
register int i;
register int any;
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
i = Py_ReprEnter((PyObject*)mp);
if (i != 0) {
if (i < 0)
return i;
fprintf(fp, "{...}");
return 0;
}
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
fprintf(fp, "{");
any = 0;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0; i <= mp->ma_mask; i++) {
Coredumpers from Michael Hudson, mutating dicts while printing or converting to string. Critical bugfix candidate -- if you take this seriously <wink>.
2001-06-02 16:02:56 +08:00
dictentry *ep = mp->ma_table + i;
PyObject *pvalue = ep->me_value;
if (pvalue != NULL) {
/* Prevent PyObject_Repr from deleting value during
key format */
Py_INCREF(pvalue);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (any++ > 0)
fprintf(fp, ", ");
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
if (PyObject_Print((PyObject *)ep->me_key, fp, 0)!=0) {
Coredumpers from Michael Hudson, mutating dicts while printing or converting to string. Critical bugfix candidate -- if you take this seriously <wink>.
2001-06-02 16:02:56 +08:00
Py_DECREF(pvalue);
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
Py_ReprLeave((PyObject*)mp);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return -1;
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
}
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
fprintf(fp, ": ");
Finish the dict->string coredump fix. Need sleep. Bugfix candidate.
2001-06-02 16:27:39 +08:00
if (PyObject_Print(pvalue, fp, 0) != 0) {
Coredumpers from Michael Hudson, mutating dicts while printing or converting to string. Critical bugfix candidate -- if you take this seriously <wink>.
2001-06-02 16:02:56 +08:00
Py_DECREF(pvalue);
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
Py_ReprLeave((PyObject*)mp);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return -1;
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
}
Coredumpers from Michael Hudson, mutating dicts while printing or converting to string. Critical bugfix candidate -- if you take this seriously <wink>.
2001-06-02 16:02:56 +08:00
Py_DECREF(pvalue);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
}
fprintf(fp, "}");
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
Py_ReprLeave((PyObject*)mp);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return 0;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_repr(dictobject *mp)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
dict_repr: Reuse one of the int vars (minor code simplification).
2001-06-16 15:52:53 +08:00
int i;
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
PyObject *s, *temp, *colon = NULL;
PyObject *pieces = NULL, *result = NULL;
PyObject *key, *value;
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
i = Py_ReprEnter((PyObject *)mp);
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
if (i != 0) {
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
return i > 0 ? PyString_FromString("{...}") : NULL;
}
if (mp->ma_used == 0) {
result = PyString_FromString("{}");
goto Done;
Use Py_Repr{Enter,Leave} to display recursive dictionaries in finite space. (Jeremy will hardly recognize his patch :-)
1998-04-11 06:47:14 +08:00
}
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
pieces = PyList_New(0);
if (pieces == NULL)
goto Done;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
colon = PyString_FromString(": ");
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
if (colon == NULL)
goto Done;
/* Do repr() on each key+value pair, and insert ": " between them.
Note that repr may mutate the dict. */
dict_repr: Reuse one of the int vars (minor code simplification).
2001-06-16 15:52:53 +08:00
i = 0;
while (PyDict_Next((PyObject *)mp, &i, &key, &value)) {
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
int status;
/* Prevent repr from deleting value during key format. */
Py_INCREF(value);
s = PyObject_Repr(key);
PyString_Concat(&s, colon);
PyString_ConcatAndDel(&s, PyObject_Repr(value));
Py_DECREF(value);
if (s == NULL)
goto Done;
status = PyList_Append(pieces, s);
Py_DECREF(s); /* append created a new ref */
if (status < 0)
goto Done;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
/* Add "{}" decorations to the first and last items. */
assert(PyList_GET_SIZE(pieces) > 0);
s = PyString_FromString("{");
if (s == NULL)
goto Done;
temp = PyList_GET_ITEM(pieces, 0);
PyString_ConcatAndDel(&s, temp);
PyList_SET_ITEM(pieces, 0, s);
if (s == NULL)
goto Done;
s = PyString_FromString("}");
if (s == NULL)
goto Done;
temp = PyList_GET_ITEM(pieces, PyList_GET_SIZE(pieces) - 1);
PyString_ConcatAndDel(&temp, s);
PyList_SET_ITEM(pieces, PyList_GET_SIZE(pieces) - 1, temp);
if (temp == NULL)
goto Done;
/* Paste them all together with ", " between. */
s = PyString_FromString(", ");
if (s == NULL)
goto Done;
result = _PyString_Join(s, pieces);
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
Py_DECREF(s);
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
Done:
Py_XDECREF(pieces);
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_XDECREF(colon);
SF bug 433228: repr(list) woes when len(list) big. Gave Python linear-time repr() implementations for dicts, lists, strings. This means, e.g., that repr(range(50000)) is no longer 50x slower than pprint.pprint() in 2.2 <wink>. I don't consider this a bugfix candidate, as it's a performance boost. Added _PyString_Join() to the internal string API. If we want that in the public API, fine, but then it requires runtime error checks instead of asserts.
2001-06-16 13:11:17 +08:00
Py_ReprLeave((PyObject *)mp);
return result;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
static int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_length(dictobject *mp)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
return mp->ma_used;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_subscript(dictobject *mp, register PyObject *key)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *v;
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
long hash;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
assert(mp->ma_table != NULL);
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#endif
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = PyObject_Hash(key);
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
if (hash == -1)
return NULL;
}
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
v = (mp->ma_lookup)(mp, key, hash) -> me_value;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (v == NULL)
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyErr_SetObject(PyExc_KeyError, key);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
else
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_INCREF(v);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return v;
}
static int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_ass_sub(dictobject *mp, PyObject *v, PyObject *w)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
if (w == NULL)
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
return PyDict_DelItem((PyObject *)mp, v);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
else
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
return PyDict_SetItem((PyObject *)mp, v, w);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
static PyMappingMethods dict_as_mapping = {
(inquiry)dict_length, /*mp_length*/
(binaryfunc)dict_subscript, /*mp_subscript*/
(objobjargproc)dict_ass_sub, /*mp_ass_subscript*/
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
};
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_keys(register dictobject *mp)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
register PyObject *v;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
register int i, j, n;
again:
n = mp->ma_used;
v = PyList_New(n);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (v == NULL)
return NULL;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
if (n != mp->ma_used) {
/* Durnit. The allocations caused the dict to resize.
* Just start over, this shouldn't normally happen.
*/
Py_DECREF(v);
goto again;
}
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0, j = 0; i <= mp->ma_mask; i++) {
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
if (mp->ma_table[i].me_value != NULL) {
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *key = mp->ma_table[i].me_key;
Py_INCREF(key);
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
PyList_SET_ITEM(v, j, key);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
j++;
}
}
return v;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_values(register dictobject *mp)
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
register PyObject *v;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
register int i, j, n;
again:
n = mp->ma_used;
v = PyList_New(n);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
if (v == NULL)
return NULL;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
if (n != mp->ma_used) {
/* Durnit. The allocations caused the dict to resize.
* Just start over, this shouldn't normally happen.
*/
Py_DECREF(v);
goto again;
}
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0, j = 0; i <= mp->ma_mask; i++) {
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
if (mp->ma_table[i].me_value != NULL) {
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *value = mp->ma_table[i].me_value;
Py_INCREF(value);
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
PyList_SET_ITEM(v, j, value);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
j++;
}
}
return v;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_items(register dictobject *mp)
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
register PyObject *v;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
register int i, j, n;
PyObject *item, *key, *value;
/* Preallocate the list of tuples, to avoid allocations during
* the loop over the items, which could trigger GC, which
* could resize the dict. :-(
*/
again:
n = mp->ma_used;
v = PyList_New(n);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
if (v == NULL)
return NULL;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
for (i = 0; i < n; i++) {
item = PyTuple_New(2);
if (item == NULL) {
Py_DECREF(v);
return NULL;
}
PyList_SET_ITEM(v, i, item);
}
if (n != mp->ma_used) {
/* Durnit. The allocations caused the dict to resize.
* Just start over, this shouldn't normally happen.
*/
Py_DECREF(v);
goto again;
}
/* Nothing we do below makes any function calls. */
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0, j = 0; i <= mp->ma_mask; i++) {
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
if (mp->ma_table[i].me_value != NULL) {
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
key = mp->ma_table[i].me_key;
value = mp->ma_table[i].me_value;
item = PyList_GET_ITEM(v, j);
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_INCREF(key);
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
PyTuple_SET_ITEM(item, 0, key);
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
Py_INCREF(value);
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
PyTuple_SET_ITEM(item, 1, value);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
j++;
}
}
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
assert(j == n);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
return v;
}
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_update(PyObject *mp, PyObject *other)
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
{
if (PyDict_Update(mp, other) < 0)
return NULL;
Py_INCREF(Py_None);
return Py_None;
}
Add PyDict_Merge(a, b, override): PyDict_Merge(a, b, 1) is the same as PyDict_Update(a, b). PyDict_Merge(a, b, 0) does something similar but leaves existing items unchanged.
2001-08-11 04:28:28 +08:00
/* Update unconditionally replaces existing items.
Merge has a 3rd argument 'override'; if set, it acts like Update,
otherwise it leaves existing items unchanged. */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
int
PyDict_Update(PyObject *a, PyObject *b)
Add PyDict_Merge(a, b, override): PyDict_Merge(a, b, 1) is the same as PyDict_Update(a, b). PyDict_Merge(a, b, 0) does something similar but leaves existing items unchanged.
2001-08-11 04:28:28 +08:00
{
return PyDict_Merge(a, b, 1);
}
int
PyDict_Merge(PyObject *a, PyObject *b, int override)
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
{
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
register PyDictObject *mp, *other;
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
register int i;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
dictentry *entry;
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
/* We accept for the argument either a concrete dictionary object,
* or an abstract "mapping" object. For the former, we can do
* things quite efficiently. For the latter, we only require that
* PyMapping_Keys() and PyObject_GetItem() be supported.
*/
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
if (a == NULL || !PyDict_Check(a) || b == NULL) {
PyErr_BadInternalCall();
return -1;
}
mp = (dictobject*)a;
if (PyDict_Check(b)) {
other = (dictobject*)b;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
if (other == mp || other->ma_used == 0)
/* a.update(a) or a.update({}); nothing to do */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return 0;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
/* Do one big resize at the start, rather than
* incrementally resizing as we insert new items. Expect
* that there will be no (or few) overlapping keys.
*/
if ((mp->ma_fill + other->ma_used)*3 >= (mp->ma_mask+1)*2) {
if (dictresize(mp, (mp->ma_used + other->ma_used)*3/2) != 0)
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return -1;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
}
for (i = 0; i <= other->ma_mask; i++) {
entry = &other->ma_table[i];
Add PyDict_Merge(a, b, override): PyDict_Merge(a, b, 1) is the same as PyDict_Update(a, b). PyDict_Merge(a, b, 0) does something similar but leaves existing items unchanged.
2001-08-11 04:28:28 +08:00
if (entry->me_value != NULL &&
(override ||
PyDict_GetItem(a, entry->me_key) == NULL)) {
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
Py_INCREF(entry->me_key);
Py_INCREF(entry->me_value);
insertdict(mp, entry->me_key, entry->me_hash,
entry->me_value);
}
}
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
}
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
else {
/* Do it the generic, slower way */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
PyObject *keys = PyMapping_Keys(b);
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
PyObject *iter;
PyObject *key, *value;
int status;
if (keys == NULL)
/* Docstring says this is equivalent to E.keys() so
* if E doesn't have a .keys() method we want
* AttributeError to percolate up. Might as well
* do the same for any other error.
*/
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return -1;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
iter = PyObject_GetIter(keys);
Py_DECREF(keys);
if (iter == NULL)
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return -1;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
for (key = PyIter_Next(iter); key; key = PyIter_Next(iter)) {
Add PyDict_Merge(a, b, override): PyDict_Merge(a, b, 1) is the same as PyDict_Update(a, b). PyDict_Merge(a, b, 0) does something similar but leaves existing items unchanged.
2001-08-11 04:28:28 +08:00
if (!override && PyDict_GetItem(a, key) != NULL) {
Py_DECREF(key);
continue;
}
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
value = PyObject_GetItem(b, key);
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
if (value == NULL) {
Py_DECREF(iter);
Py_DECREF(key);
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return -1;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
}
Add PyDict_Merge(a, b, override): PyDict_Merge(a, b, 1) is the same as PyDict_Update(a, b). PyDict_Merge(a, b, 0) does something similar but leaves existing items unchanged.
2001-08-11 04:28:28 +08:00
status = PyDict_SetItem(a, key, value);
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
Py_DECREF(key);
Py_DECREF(value);
if (status < 0) {
Py_DECREF(iter);
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return -1;
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
}
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
}
dict_update(): Generalize this method so {}.update() accepts any "mapping" object, specifically one that supports PyMapping_Keys() and PyObject_GetItem(). This allows you to say e.g. {}.update(UserDict()) We keep the special case for concrete dict objects, although that seems moderately questionable. OTOH, the code exists and works, so why change that? .update()'s docstring already claims that D.update(E) implies calling E.keys() so it's appropriate not to transform AttributeErrors in PyMapping_Keys() to TypeErrors. Patch eyeballed by Tim.
2001-06-27 04:08:32 +08:00
Py_DECREF(iter);
if (PyErr_Occurred())
/* Iterator completed, via error */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return -1;
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
}
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
return 0;
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
}
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_copy(register dictobject *mp)
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
{
Add PyDict_Copy() function to C API for dicts. It returns a new dictionary that contains the same key/value pairs as p.
2000-03-31 06:27:31 +08:00
return PyDict_Copy((PyObject*)mp);
}
PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Copy(PyObject *o)
Add PyDict_Copy() function to C API for dicts. It returns a new dictionary that contains the same key/value pairs as p.
2000-03-31 06:27:31 +08:00
{
register dictobject *mp;
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
register int i;
dictobject *copy;
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
dictentry *entry;
Add PyDict_Copy() function to C API for dicts. It returns a new dictionary that contains the same key/value pairs as p.
2000-03-31 06:27:31 +08:00
if (o == NULL || !PyDict_Check(o)) {
PyErr_BadInternalCall();
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
return NULL;
Add PyDict_Copy() function to C API for dicts. It returns a new dictionary that contains the same key/value pairs as p.
2000-03-31 06:27:31 +08:00
}
mp = (dictobject *)o;
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
copy = (dictobject *)PyDict_New();
if (copy == NULL)
return NULL;
if (mp->ma_used > 0) {
if (dictresize(copy, mp->ma_used*3/2) != 0)
return NULL;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0; i <= mp->ma_mask; i++) {
Added dict.absorb() and dict.copy().
1997-05-29 03:15:28 +08:00
entry = &mp->ma_table[i];
if (entry->me_value != NULL) {
Py_INCREF(entry->me_key);
Py_INCREF(entry->me_value);
insertdict(copy, entry->me_key, entry->me_hash,
entry->me_value);
}
}
}
return (PyObject *)copy;
}
Added getmappingsize(). (Needed by previous checkin of posixmodule.c)
1993-11-05 18:18:44 +08:00
int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Size(PyObject *mp)
Added getmappingsize(). (Needed by previous checkin of posixmodule.c)
1993-11-05 18:18:44 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (mp == NULL || !PyDict_Check(mp)) {
PyErr_BadInternalCall();
* timemodule.c: Add hack for Solaris 2. * posixmodule.c: don't prototype getcwd() -- it's not portable... * mappingobject.c: double-check validity of last_name_char in dict{lookup,insert,remove}. * arraymodule.c: need memmove only for non-STDC Suns. * Makefile: comment out HTML_LIBS and XT_USE by default * pythonmain.c: don't prototype getopt() -- it's not standardized * socketmodule.c: cast flags arg to {get,set}sockopt() and addrbuf arg to recvfrom() to (ANY*). * pythonrun.c (initsigs): fix prototype, make it static * intobject.c (LONG_BIT): only #define it if not already defined * classobject.[ch]: remove all references to unused instance_convert() * mappingobject.c (getmappingsize): Don't return NULL in int function.
1993-11-24 01:53:17 +08:00
return 0;
Added getmappingsize(). (Needed by previous checkin of posixmodule.c)
1993-11-05 18:18:44 +08:00
}
Renamed from mappingobject.c to dictobject.c. (Sorry Jack, all your projects will have to be changed again. :-( )
1997-05-14 05:02:11 +08:00
return ((dictobject *)mp)->ma_used;
Added getmappingsize(). (Needed by previous checkin of posixmodule.c)
1993-11-05 18:18:44 +08:00
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Keys(PyObject *mp)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (mp == NULL || !PyDict_Check(mp)) {
PyErr_BadInternalCall();
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
return NULL;
}
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
return dict_keys((dictobject *)mp);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Values(PyObject *mp)
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (mp == NULL || !PyDict_Check(mp)) {
PyErr_BadInternalCall();
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
return NULL;
}
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
return dict_values((dictobject *)mp);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_Items(PyObject *mp)
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
if (mp == NULL || !PyDict_Check(mp)) {
PyErr_BadInternalCall();
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
return NULL;
}
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
return dict_items((dictobject *)mp);
Several changes in one: (1) dictionaries/mappings now have attributes values() and items() as well as keys(); at the C level, use the new function mappinggetnext() to iterate over a dictionary. (2) "class C(): ..." is now illegal; you must write "class C: ...". (3) Class objects now know their own name (finally!); and minor improvements to the way how classes, functions and methods are represented as strings. (4) Added an "access" statement and semantics. (This is still experimental -- as long as you don't use the keyword 'access' nothing should be changed.)
1993-05-19 22:50:45 +08:00
}
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
/* Subroutine which returns the smallest key in a for which b's value
is different or absent. The value is returned too, through the
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
pval argument. Both are NULL if no key in a is found for which b's status
differs. The refcounts on (and only on) non-NULL *pval and function return
values must be decremented by the caller (characterize() increments them
to ensure that mutating comparison and PyDict_GetItem calls can't delete
them before the caller is done looking at them). */
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
characterize(dictobject *a, dictobject *b, PyObject **pval)
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
{
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
PyObject *akey = NULL; /* smallest key in a s.t. a[akey] != b[akey] */
PyObject *aval = NULL; /* a[akey] */
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
int i, cmp;
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0; i <= a->ma_mask; i++) {
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
PyObject *thiskey, *thisaval, *thisbval;
if (a->ma_table[i].me_value == NULL)
continue;
thiskey = a->ma_table[i].me_key;
Py_INCREF(thiskey); /* keep alive across compares */
if (akey != NULL) {
cmp = PyObject_RichCompareBool(akey, thiskey, Py_LT);
if (cmp < 0) {
Py_DECREF(thiskey);
goto Fail;
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
}
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
if (cmp > 0 ||
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
i > a->ma_mask ||
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
a->ma_table[i].me_value == NULL)
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
{
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
/* Not the *smallest* a key; or maybe it is
* but the compare shrunk the dict so we can't
* find its associated value anymore; or
* maybe it is but the compare deleted the
* a[thiskey] entry.
*/
Py_DECREF(thiskey);
continue;
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
}
}
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
/* Compare a[thiskey] to b[thiskey]; cmp <- true iff equal. */
thisaval = a->ma_table[i].me_value;
assert(thisaval);
Py_INCREF(thisaval); /* keep alive */
thisbval = PyDict_GetItem((PyObject *)b, thiskey);
if (thisbval == NULL)
cmp = 0;
else {
/* both dicts have thiskey: same values? */
cmp = PyObject_RichCompareBool(
thisaval, thisbval, Py_EQ);
if (cmp < 0) {
Py_DECREF(thiskey);
Py_DECREF(thisaval);
goto Fail;
}
}
if (cmp == 0) {
/* New winner. */
Py_XDECREF(akey);
Py_XDECREF(aval);
akey = thiskey;
aval = thisaval;
}
else {
Py_DECREF(thiskey);
Py_DECREF(thisaval);
}
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
}
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
*pval = aval;
return akey;
Fail:
Py_XDECREF(akey);
Py_XDECREF(aval);
*pval = NULL;
return NULL;
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
}
static int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_compare(dictobject *a, dictobject *b)
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *adiff, *bdiff, *aval, *bval;
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
int res;
/* Compare lengths first */
if (a->ma_used < b->ma_used)
return -1; /* a is shorter */
else if (a->ma_used > b->ma_used)
return 1; /* b is shorter */
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
/* Same length -- check all keys */
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
bdiff = bval = NULL;
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
adiff = characterize(a, b, &aval);
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
if (adiff == NULL) {
assert(!aval);
Repair typo in comment.
2001-05-11 02:58:31 +08:00
/* Either an error, or a is a subset with the same length so
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
* must be equal.
*/
res = PyErr_Occurred() ? -1 : 0;
goto Finished;
}
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
bdiff = characterize(b, a, &bval);
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
if (bdiff == NULL && PyErr_Occurred()) {
assert(!bval);
res = -1;
goto Finished;
}
res = 0;
if (bdiff) {
/* bdiff == NULL "should be" impossible now, but perhaps
* the last comparison done by the characterize() on a had
* the side effect of making the dicts equal!
*/
res = PyObject_Compare(adiff, bdiff);
}
if (res == 0 && bval != NULL)
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
res = PyObject_Compare(aval, bval);
SF bug #422121 Insecurities in dict comparison. Fixed a half dozen ways in which general dict comparison could crash Python (even cause Win98SE to reboot) in the presence of kay and/or value comparison routines that mutate the dict during dict comparison. Bugfix candidate.
2001-05-10 16:32:44 +08:00
Finished:
Py_XDECREF(adiff);
Py_XDECREF(bdiff);
Py_XDECREF(aval);
Py_XDECREF(bval);
Experimental new implementation of dictionary comparison. This defines that a shorter dictionary is always smaller than a longer one. For dictionaries of the same size, the smallest differing element determines the outcome (which yields the same results as before, without explicit sorting).
1996-12-06 05:55:55 +08:00
return res;
}
SF patch #421922: Implement rich comparison for dicts. d1 == d2 and d1 != d2 now work even if the keys and values in d1 and d2 don't support comparisons other than ==, and testing dicts for equality is faster now (especially when inequality obtains).
2001-05-08 12:38:29 +08:00
/* Return 1 if dicts equal, 0 if not, -1 if error.
* Gets out as soon as any difference is detected.
* Uses only Py_EQ comparison.
*/
static int
dict_equal(dictobject *a, dictobject *b)
{
int i;
if (a->ma_used != b->ma_used)
/* can't be equal if # of entries differ */
return 0;
New collision resolution scheme: no polynomials, simpler, faster, less code, less memory. Tests have uncovered no drawbacks. Christian and Vladimir are the other two people who have burned many brain cells on the dict code in recent years, and they like the approach too, so I'm checking it in without further ado.
2001-06-02 13:27:19 +08:00
SF patch #421922: Implement rich comparison for dicts. d1 == d2 and d1 != d2 now work even if the keys and values in d1 and d2 don't support comparisons other than ==, and testing dicts for equality is faster now (especially when inequality obtains).
2001-05-08 12:38:29 +08:00
/* Same # of entries -- check all of 'em. Exit early on any diff. */
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
for (i = 0; i <= a->ma_mask; i++) {
SF patch #421922: Implement rich comparison for dicts. d1 == d2 and d1 != d2 now work even if the keys and values in d1 and d2 don't support comparisons other than ==, and testing dicts for equality is faster now (especially when inequality obtains).
2001-05-08 12:38:29 +08:00
PyObject *aval = a->ma_table[i].me_value;
if (aval != NULL) {
int cmp;
PyObject *bval;
PyObject *key = a->ma_table[i].me_key;
/* temporarily bump aval's refcount to ensure it stays
alive until we're done with it */
Py_INCREF(aval);
bval = PyDict_GetItem((PyObject *)b, key);
if (bval == NULL) {
Py_DECREF(aval);
return 0;
}
cmp = PyObject_RichCompareBool(aval, bval, Py_EQ);
Py_DECREF(aval);
if (cmp <= 0) /* error or not equal */
return cmp;
}
}
return 1;
}
static PyObject *
dict_richcompare(PyObject *v, PyObject *w, int op)
{
int cmp;
PyObject *res;
if (!PyDict_Check(v) || !PyDict_Check(w)) {
res = Py_NotImplemented;
}
else if (op == Py_EQ || op == Py_NE) {
cmp = dict_equal((dictobject *)v, (dictobject *)w);
if (cmp < 0)
return NULL;
res = (cmp == (op == Py_EQ)) ? Py_True : Py_False;
}
Restore dicts' tp_compare slot, and change dict_richcompare to say it doesn't know how to do LE, LT, GE, GT. dict_richcompare can't do the latter any faster than dict_compare can. More importantly, for cmp(dict1, dict2), Python *first* tries rich compares with EQ, LT, and GT one at a time, even if the tp_compare slot is defined, and dict_richcompare called dict_compare for the latter two because it couldn't do them itself. The result was a lot of wasted calls to dict_compare. Now dict_richcompare gives up at once the times Python calls it with LT and GT from try_rich_to_3way_compare(), and dict_compare is called only once (when Python gets around to trying the tp_compare slot). Continued mystery: despite that this cut the number of calls to dict_compare approximately in half in test_mutants.py, the latter still runs amazingly slowly. Running under the debugger doesn't show excessive activity in the dict comparison code anymore, so I'm guessing the culprit is somewhere else -- but where? Perhaps in the element (key/value) comparison code? We clearly spend a lot of time figuring out how to compare things.
2001-05-11 05:45:19 +08:00
else
res = Py_NotImplemented;
SF patch #421922: Implement rich comparison for dicts. d1 == d2 and d1 != d2 now work even if the keys and values in d1 and d2 don't support comparisons other than ==, and testing dicts for equality is faster now (especially when inequality obtains).
2001-05-08 12:38:29 +08:00
Py_INCREF(res);
return res;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_has_key(register dictobject *mp, PyObject *key)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
long hash;
register long ok;
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
Several optimizations and speed improvements. cstubs: Use Matrix type instead of float[4][4].
1993-10-22 20:04:32 +08:00
#endif
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
hash = PyObject_Hash(key);
Forget keeping track of whether a dictionary contains all interned string keys. Just doing a pointer compare before the string compare (in fact before the hash compare!) is just as fast.
1997-01-24 03:39:29 +08:00
if (hash == -1)
return NULL;
}
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
ok = (mp->ma_lookup)(mp, key, hash)->me_value != NULL;
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
return PyInt_FromLong(ok);
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
dict_get(): New method for item access with different semantics than __getitem__(). This method never raises an exception; if the key is not in the dictionary, the second (optional) argument is returned. If the second argument is not provided and the key is missing, None is returned. mapp_methods: added "get" method.
1997-10-07 01:49:20 +08:00
static PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
dict_get(register dictobject *mp, PyObject *args)
dict_get(): New method for item access with different semantics than __getitem__(). This method never raises an exception; if the key is not in the dictionary, the second (optional) argument is returned. If the second argument is not provided and the key is missing, None is returned. mapp_methods: added "get" method.
1997-10-07 01:49:20 +08:00
{
PyObject *key;
dict_get(): Fixed a couple of stupid mistakes which caused crashes. Also got rid of some unnecessary code.
1997-10-21 01:26:25 +08:00
PyObject *failobj = Py_None;
dict_get(): New method for item access with different semantics than __getitem__(). This method never raises an exception; if the key is not in the dictionary, the second (optional) argument is returned. If the second argument is not provided and the key is missing, None is returned. mapp_methods: added "get" method.
1997-10-07 01:49:20 +08:00
PyObject *val = NULL;
long hash;
dict_has_key(): Accept only one parameter. PR#210 reported by Andreas Jung <ajung@sz-sb.de>.
2000-02-23 23:47:16 +08:00
if (!PyArg_ParseTuple(args, "O|O:get", &key, &failobj))
dict_get(): New method for item access with different semantics than __getitem__(). This method never raises an exception; if the key is not in the dictionary, the second (optional) argument is returned. If the second argument is not provided and the key is missing, None is returned. mapp_methods: added "get" method.
1997-10-07 01:49:20 +08:00
return NULL;
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
dict_get(): New method for item access with different semantics than __getitem__(). This method never raises an exception; if the key is not in the dictionary, the second (optional) argument is returned. If the second argument is not provided and the key is missing, None is returned. mapp_methods: added "get" method.
1997-10-07 01:49:20 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
#endif
{
hash = PyObject_Hash(key);
if (hash == -1)
return NULL;
}
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
val = (mp->ma_lookup)(mp, key, hash)->me_value;
dict_get(): Fixed a couple of stupid mistakes which caused crashes. Also got rid of some unnecessary code.
1997-10-21 01:26:25 +08:00
dict_get(): New method for item access with different semantics than __getitem__(). This method never raises an exception; if the key is not in the dictionary, the second (optional) argument is returned. If the second argument is not provided and the key is missing, None is returned. mapp_methods: added "get" method.
1997-10-07 01:49:20 +08:00
if (val == NULL)
val = failobj;
Py_INCREF(val);
return val;
}
Barry's patch to implement the new setdefault() method.
2000-08-09 00:12:54 +08:00
static PyObject *
dict_setdefault(register dictobject *mp, PyObject *args)
{
PyObject *key;
PyObject *failobj = Py_None;
PyObject *val = NULL;
long hash;
if (!PyArg_ParseTuple(args, "O|O:setdefault", &key, &failobj))
return NULL;
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
Barry's patch to implement the new setdefault() method.
2000-08-09 00:12:54 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
#endif
{
hash = PyObject_Hash(key);
if (hash == -1)
return NULL;
}
Slight performance hack that also avoids requiring the existence of thread state for dictionaries that have only been indexed by string keys. See the comments in SourceForge for more. This closes SourceForge patch #101309.
2000-09-01 03:31:38 +08:00
val = (mp->ma_lookup)(mp, key, hash)->me_value;
Barry's patch to implement the new setdefault() method.
2000-08-09 00:12:54 +08:00
if (val == NULL) {
val = failobj;
if (PyDict_SetItem((PyObject*)mp, key, failobj))
val = NULL;
}
Py_XINCREF(val);
return val;
}
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_clear(register dictobject *mp)
Add clear() method to dictionary objects.
1997-03-22 05:55:12 +08:00
{
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyDict_Clear((PyObject *)mp);
Py_INCREF(Py_None);
return Py_None;
Add clear() method to dictionary objects.
1997-03-22 05:55:12 +08:00
}
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_popitem(dictobject *mp)
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
{
int i = 0;
dictentry *ep;
PyObject *res;
dict_popitem(): Repaired last-second 2.1 comment, which misidentified the true reason for allocating the tuple before checking the dict size.
2001-06-02 13:42:29 +08:00
/* Allocate the result tuple before checking the size. Believe it
* or not, this allocation could trigger a garbage collection which
* could empty the dict, so if we checked the size first and that
* happened, the result would be an infinite loop (searching for an
* entry that no longer exists). Note that the usual popitem()
* idiom is "while d: k, v = d.popitem()". so needing to throw the
* tuple away if the dict *is* empty isn't a significant
* inefficiency -- possible, but unlikely in practice.
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
*/
res = PyTuple_New(2);
if (res == NULL)
return NULL;
Tim pointed out a remaining vulnerability in popitem(): the PyTuple_New() could *conceivably* clear the dict, so move the test for an empty dict after the tuple allocation. It means that we waste time allocating and deallocating a 2-tuple when the dict is empty, but who cares. It also means that when the dict is empty *and* there's no memory to allocate a 2-tuple, we raise MemoryError, not KeyError -- but that may actually a good idea: if there's no room for a lousy 2-tuple, what are the chances that there's room for a KeyError instance?
2001-04-16 08:02:32 +08:00
if (mp->ma_used == 0) {
Py_DECREF(res);
PyErr_SetString(PyExc_KeyError,
"popitem(): dictionary is empty");
return NULL;
}
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
/* Set ep to "the first" dict entry with a value. We abuse the hash
* field of slot 0 to hold a search finger:
* If slot 0 has a value, use slot 0.
* Else slot 0 is being used to hold a search finger,
* and we use its hash value as the first index to look.
*/
ep = &mp->ma_table[0];
if (ep->me_value == NULL) {
i = (int)ep->me_hash;
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
/* The hash field may be a real hash value, or it may be a
* legit search finger, or it may be a once-legit search
* finger that's out of bounds now because it wrapped around
* or the table shrunk -- simply make sure it's in bounds now.
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
*/
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
if (i > mp->ma_mask || i < 1)
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
i = 1; /* skip slot 0 */
while ((ep = &mp->ma_table[i])->me_value == NULL) {
i++;
Store the mask instead of the size in dictobjects. The mask is more frequently used, and in particular this allows to drop the last remaining obvious time-waster in the crucial lookdict() and lookdict_string() functions. Other changes consist mostly of changing "i < ma_size" to "i <= ma_mask" everywhere.
2001-06-05 05:00:21 +08:00
if (i > mp->ma_mask)
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
i = 1;
}
}
Tentative fix for a problem that Tim discovered at the last moment, and reported to python-dev: because we were calling dict_resize() in PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(), and because PyTuple_New() can cause GC, and because dict_items() calls PyTuple_New(), it was possible for dict_items() to have the dict resized right under its nose. The solution is convoluted, and touches several places: keys(), values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem(). There are two parts to it. First, we no longer call dict_resize() in PyDict_Next(), which seems to solve the immediate problem. But then PyDict_SetItem() must have a different policy about when *it* calls dict_resize(), because we want to guarantee (e.g. for an algorithm that Jeremy uses in the compiler) that you can loop over a dict using PyDict_Next() and make changes to the dict as long as those changes are only value replacements for existing keys using PyDict_SetItem(). This is done by resizing *after* the insertion instead of before, and by remembering the size before we insert the item, and if the size is still the same, we don't bother to even check if we might need to resize. An additional detail is that if the dict starts out empty, we must still resize it before the insertion. That was the first part. :-) The second part is to make keys(), values(), items(), and popitem() safe against side effects on the dict caused by allocations, under the assumption that if the GC can cause arbitrary Python code to run, it can cause other threads to run, and it's not inconceivable that our dict could be resized -- it would be insane to write code that relies on this, but not all code is sane. Now, I have this nagging feeling that the loops in lookdict probably are blissfully assuming that doing a simple key comparison does not change the dict's size. This is not necessarily true (the keys could be class instances after all). But that's a battle for another day.
2001-04-16 06:16:26 +08:00
PyTuple_SET_ITEM(res, 0, ep->me_key);
PyTuple_SET_ITEM(res, 1, ep->me_value);
Py_INCREF(dummy);
ep->me_key = dummy;
ep->me_value = NULL;
mp->ma_used--;
assert(mp->ma_table[0].me_value == NULL);
mp->ma_table[0].me_hash = i + 1; /* next place to start */
Add popitem() -- SF patch #102733.
2000-12-13 06:02:18 +08:00
return res;
}
Round 1 of Neil Schemenauer's GC patches: This patch adds the type methods traverse and clear necessary for GC implementation.
2000-06-23 22:18:11 +08:00
static int
dict_traverse(PyObject *op, visitproc visit, void *arg)
{
int i = 0, err;
PyObject *pk;
PyObject *pv;
while (PyDict_Next(op, &i, &pk, &pv)) {
err = visit(pk, arg);
if (err)
return err;
err = visit(pv, arg);
if (err)
return err;
}
return 0;
}
static int
dict_tp_clear(PyObject *op)
{
PyDict_Clear(op);
return 0;
}
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
staticforward PyObject *dictiter_new(dictobject *, binaryfunc);
static PyObject *
select_key(PyObject *key, PyObject *value)
{
Py_INCREF(key);
return key;
}
static PyObject *
select_value(PyObject *key, PyObject *value)
{
Py_INCREF(value);
return value;
}
static PyObject *
select_item(PyObject *key, PyObject *value)
{
PyObject *res = PyTuple_New(2);
if (res != NULL) {
Py_INCREF(key);
Py_INCREF(value);
PyTuple_SET_ITEM(res, 0, key);
PyTuple_SET_ITEM(res, 1, value);
}
return res;
}
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_iterkeys(dictobject *dict)
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
{
return dictiter_new(dict, select_key);
}
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_itervalues(dictobject *dict)
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
{
return dictiter_new(dict, select_value);
}
static PyObject *
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
dict_iteritems(dictobject *dict)
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
{
return dictiter_new(dict, select_item);
}
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
static char has_key__doc__[] =
"D.has_key(k) -> 1 if D has a key k, else 0";
static char get__doc__[] =
"D.get(k[,d]) -> D[k] if D.has_key(k), else d. d defaults to None.";
static char setdefault_doc__[] =
"D.setdefault(k[,d]) -> D.get(k,d), also set D[k]=d if not D.has_key(k)";
static char popitem__doc__[] =
"D.popitem() -> (k, v), remove and return some (key, value) pair as a\n\
2-tuple; but raise KeyError if D is empty";
static char keys__doc__[] =
"D.keys() -> list of D's keys";
static char items__doc__[] =
"D.items() -> list of D's (key, value) pairs, as 2-tuples";
static char values__doc__[] =
"D.values() -> list of D's values";
static char update__doc__[] =
"D.update(E) -> None. Update D from E: for k in E.keys(): D[k] = E[k]";
static char clear__doc__[] =
"D.clear() -> None. Remove all items from D.";
static char copy__doc__[] =
"D.copy() -> a shallow copy of D";
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
static char iterkeys__doc__[] =
"D.iterkeys() -> an iterator over the keys of D";
static char itervalues__doc__[] =
"D.itervalues() -> an iterator over the values of D";
static char iteritems__doc__[] =
"D.iteritems() -> an iterator over the (key, value) items of D";
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
static PyMethodDef mapp_methods[] = {
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"has_key", (PyCFunction)dict_has_key, METH_O,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
has_key__doc__},
{"get", (PyCFunction)dict_get, METH_VARARGS,
get__doc__},
{"setdefault", (PyCFunction)dict_setdefault, METH_VARARGS,
setdefault_doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"popitem", (PyCFunction)dict_popitem, METH_NOARGS,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
popitem__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"keys", (PyCFunction)dict_keys, METH_NOARGS,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
keys__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"items", (PyCFunction)dict_items, METH_NOARGS,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
items__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"values", (PyCFunction)dict_values, METH_NOARGS,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
values__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"update", (PyCFunction)dict_update, METH_O,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
update__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"clear", (PyCFunction)dict_clear, METH_NOARGS,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
clear__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"copy", (PyCFunction)dict_copy, METH_NOARGS,
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
copy__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"iterkeys", (PyCFunction)dict_iterkeys, METH_NOARGS,
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
iterkeys__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"itervalues", (PyCFunction)dict_itervalues, METH_NOARGS,
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
itervalues__doc__},
Patch #427190: Implement and use METH_NOARGS and METH_O.
2001-08-16 21:15:00 +08:00
{"iteritems", (PyCFunction)dict_iteritems, METH_NOARGS,
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
iteritems__doc__},
Add long-overdue docstrings to dict methods.
2000-12-14 07:18:45 +08:00
{NULL, NULL} /* sentinel */
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
};
Implement, test and document "key in dict" and "key not in dict". I know some people don't like this -- if it's really controversial, I'll take it out again. (If it's only Alex Martelli who doesn't like it, that doesn't count as "real controversial" though. :-) That's why this is a separate checkin from the iterators stuff I'm about to check in next.
2001-04-21 00:50:40 +08:00
static int
dict_contains(dictobject *mp, PyObject *key)
{
long hash;
#ifdef CACHE_HASH
Changed the dict implementation to take "string shortcuts" only when keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
2001-09-14 08:25:33 +08:00
if (!PyString_CheckExact(key) ||
Implement, test and document "key in dict" and "key not in dict". I know some people don't like this -- if it's really controversial, I'll take it out again. (If it's only Alex Martelli who doesn't like it, that doesn't count as "real controversial" though. :-) That's why this is a separate checkin from the iterators stuff I'm about to check in next.
2001-04-21 00:50:40 +08:00
(hash = ((PyStringObject *) key)->ob_shash) == -1)
#endif
{
hash = PyObject_Hash(key);
if (hash == -1)
return -1;
}
SF patch #425242: Patch which "inlines" small dictionaries. The idea is Marc-Andre Lemburg's, the implementation is Tim's. Add a new ma_smalltable member to dictobjects, an embedded vector of MINSIZE (8) dictentry structs. Short course is that this lets us avoid additional malloc(s) for dicts with no more than 5 entries. The changes are widespread but mostly small. Long course: WRT speed, all scalar operations (getitem, setitem, delitem) on non-empty dicts benefit from no longer needing NULL-pointer checks (ma_table is never NULL anymore). Bulk operations (copy, update, resize, clearing slots during dealloc) benefit in some cases from now looping on the ma_fill count rather than on ma_size, but that was an unexpected benefit: the original reason to loop on ma_fill was to let bulk operations on empty dicts end quickly (since the NULL-pointer checks went away, empty dicts aren't special-cased any more). Special considerations: For dicts that remain empty, this change is a lose on two counts: the dict object contains 8 new dictentry slots now that weren't needed before, and dict object creation also spends time memset'ing these doomed-to-be-unsused slots to NULLs. For dicts with one or two entries that never get larger than 2, it's a mix: a malloc()/free() pair is no longer needed, and the 2-entry case gets to use 8 slots (instead of 4) thus decreasing the chance of collision. Against that, dict object creation spends time memset'ing 4 slots that aren't strictly needed in this case. For dicts with 3 through 5 entries that never get larger than 5, it's a pure win: the dict is created with all the space they need, and they never need to resize. Before they suffered two malloc()/free() calls, plus 1 dict resize, to get enough space. In addition, the 8-slot table they ended with consumed more memory overall, because of the hidden overhead due to the additional malloc. For dicts with 6 or more entries, the ma_smalltable member is wasted space, but then these are large(r) dicts so 8 slots more or less doesn't make much difference. They still benefit all the time from removing ubiquitous dynamic null-pointer checks, and get a small benefit (but relatively smaller the larger the dict) from not having to do two mallocs, two frees, and a resize on the way *to* getting their sixth entry. All in all it appears a small but definite general win, with larger benefits in specific cases. It's especially nice that it allowed to get rid of several branches, gotos and labels, and overall made the code smaller.
2001-05-23 04:40:22 +08:00
return (mp->ma_lookup)(mp, key, hash)->me_value != NULL;
Implement, test and document "key in dict" and "key not in dict". I know some people don't like this -- if it's really controversial, I'll take it out again. (If it's only Alex Martelli who doesn't like it, that doesn't count as "real controversial" though. :-) That's why this is a separate checkin from the iterators stuff I'm about to check in next.
2001-04-21 00:50:40 +08:00
}
/* Hack to implement "key in dict" */
static PySequenceMethods dict_as_sequence = {
0, /* sq_length */
0, /* sq_concat */
0, /* sq_repeat */
0, /* sq_item */
0, /* sq_slice */
0, /* sq_ass_item */
0, /* sq_ass_slice */
(objobjproc)dict_contains, /* sq_contains */
0, /* sq_inplace_concat */
0, /* sq_inplace_repeat */
};
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
static PyObject *
dict_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
PyObject *self;
assert(type != NULL && type->tp_alloc != NULL);
self = type->tp_alloc(type, 0);
if (self != NULL) {
PyDictObject *d = (PyDictObject *)self;
/* It's guaranteed that tp->alloc zeroed out the struct. */
assert(d->ma_table == NULL && d->ma_fill == 0 && d->ma_used == 0);
INIT_NONZERO_DICT_SLOTS(d);
d->ma_lookup = lookdict_string;
#ifdef SHOW_CONVERSION_COUNTS
++created;
#endif
}
return self;
}
Make dictionary() a real constructor. Accepts at most one argument, "a mapping object", in the same sense dict.update(x) requires of x (that x has a keys() method and a getitem). Questionable: The other type constructors accept a keyword argument, so I did that here too (e.g., dictionary(mapping={1:2}) works). But type_call doesn't pass the keyword args to the tp_new slot (it passes NULL), it only passes them to the tp_init slot, so getting at them required adding a tp_init slot to dicts. Looks like that makes the normal case (i.e., no args at all) a little slower (the time it takes to call dict.tp_init and have it figure out there's nothing to do).
2001-09-02 16:22:48 +08:00
static int
dict_init(PyObject *self, PyObject *args, PyObject *kwds)
{
PyObject *arg = NULL;
static char *kwlist[] = {"mapping", 0};
if (!PyArg_ParseTupleAndKeywords(args, kwds, "|O:dictionary",
kwlist, &arg))
return -1;
if (arg != NULL) {
if (PyDict_Merge(self, arg, 1) < 0) {
Repair typo in comment.
2001-09-03 02:35:54 +08:00
/* An error like "AttributeError: keys" is too
Make dictionary() a real constructor. Accepts at most one argument, "a mapping object", in the same sense dict.update(x) requires of x (that x has a keys() method and a getitem). Questionable: The other type constructors accept a keyword argument, so I did that here too (e.g., dictionary(mapping={1:2}) works). But type_call doesn't pass the keyword args to the tp_new slot (it passes NULL), it only passes them to the tp_init slot, so getting at them required adding a tp_init slot to dicts. Looks like that makes the normal case (i.e., no args at all) a little slower (the time it takes to call dict.tp_init and have it figure out there's nothing to do).
2001-09-02 16:22:48 +08:00
cryptic in this context. */
if (PyErr_ExceptionMatches(PyExc_AttributeError)) {
PyErr_SetString(PyExc_TypeError,
"argument must be of a mapping type");
}
return -1;
}
}
return 0;
}
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
static PyObject *
dict_iter(dictobject *dict)
{
return dictiter_new(dict, select_key);
}
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
Make dictionary() a real constructor. Accepts at most one argument, "a mapping object", in the same sense dict.update(x) requires of x (that x has a keys() method and a getitem). Questionable: The other type constructors accept a keyword argument, so I did that here too (e.g., dictionary(mapping={1:2}) works). But type_call doesn't pass the keyword args to the tp_new slot (it passes NULL), it only passes them to the tp_init slot, so getting at them required adding a tp_init slot to dicts. Looks like that makes the normal case (i.e., no args at all) a little slower (the time it takes to call dict.tp_init and have it figure out there's nothing to do).
2001-09-02 16:22:48 +08:00
static char dictionary_doc[] =
"dictionary() -> new empty dictionary\n"
"dictionary(mapping) -> new dict initialized from mapping's key+value pairs";
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyTypeObject PyDict_Type = {
PyObject_HEAD_INIT(&PyType_Type)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
0,
* Changed all copyright messages to include 1993. * Stubs for faster implementation of local variables (not yet finished) * Added function name to code object. Print it for code and function objects. THIS MAKES THE .PYC FILE FORMAT INCOMPATIBLE (the version number has changed accordingly) * Print address of self for built-in methods * New internal functions getattro and setattro (getattr/setattr with string object arg) * Replaced "dictobject" with more powerful "mappingobject" * New per-type functio tp_hash to implement arbitrary object hashing, and hashobject() to interface to it * Added built-in functions hash(v) and hasattr(v, 'name') * classobject: made some functions static that accidentally weren't; added __hash__ special instance method to implement hash() * Added proper comparison for built-in methods and functions
1993-03-29 18:43:31 +08:00
"dictionary",
Use new GC API.
2001-08-30 07:54:21 +08:00
sizeof(dictobject),
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
0,
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
(destructor)dict_dealloc, /* tp_dealloc */
(printfunc)dict_print, /* tp_print */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
0, /* tp_getattr */
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
0, /* tp_setattr */
Restore dicts' tp_compare slot, and change dict_richcompare to say it doesn't know how to do LE, LT, GE, GT. dict_richcompare can't do the latter any faster than dict_compare can. More importantly, for cmp(dict1, dict2), Python *first* tries rich compares with EQ, LT, and GT one at a time, even if the tp_compare slot is defined, and dict_richcompare called dict_compare for the latter two because it couldn't do them itself. The result was a lot of wasted calls to dict_compare. Now dict_richcompare gives up at once the times Python calls it with LT and GT from try_rich_to_3way_compare(), and dict_compare is called only once (when Python gets around to trying the tp_compare slot). Continued mystery: despite that this cut the number of calls to dict_compare approximately in half in test_mutants.py, the latter still runs amazingly slowly. Running under the debugger doesn't show excessive activity in the dict comparison code anymore, so I'm guessing the culprit is somewhere else -- but where? Perhaps in the element (key/value) comparison code? We clearly spend a lot of time figuring out how to compare things.
2001-05-11 05:45:19 +08:00
(cmpfunc)dict_compare, /* tp_compare */
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
(reprfunc)dict_repr, /* tp_repr */
0, /* tp_as_number */
Implement, test and document "key in dict" and "key not in dict". I know some people don't like this -- if it's really controversial, I'll take it out again. (If it's only Alex Martelli who doesn't like it, that doesn't count as "real controversial" though. :-) That's why this is a separate checkin from the iterators stuff I'm about to check in next.
2001-04-21 00:50:40 +08:00
&dict_as_sequence, /* tp_as_sequence */
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
&dict_as_mapping, /* tp_as_mapping */
0, /* tp_hash */
0, /* tp_call */
0, /* tp_str */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
PyObject_GenericGetAttr, /* tp_getattro */
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
0, /* tp_setattro */
0, /* tp_as_buffer */
Use new GC API.
2001-08-30 07:54:21 +08:00
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC |
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
Py_TPFLAGS_BASETYPE, /* tp_flags */
Make dictionary() a real constructor. Accepts at most one argument, "a mapping object", in the same sense dict.update(x) requires of x (that x has a keys() method and a getitem). Questionable: The other type constructors accept a keyword argument, so I did that here too (e.g., dictionary(mapping={1:2}) works). But type_call doesn't pass the keyword args to the tp_new slot (it passes NULL), it only passes them to the tp_init slot, so getting at them required adding a tp_init slot to dicts. Looks like that makes the normal case (i.e., no args at all) a little slower (the time it takes to call dict.tp_init and have it figure out there's nothing to do).
2001-09-02 16:22:48 +08:00
dictionary_doc, /* tp_doc */
Rich comparisons: - Use PyObject_RichCompareBool() when comparing keys; this makes the error handling cleaner. - There were two implementations for dictionary comparison, an old one (#ifdef'ed out) and a new one. Got rid of the old one, which was abandoned years ago. - In the characterize() function, part of dictionary comparison, use PyObject_RichCompareBool() to compare keys and values instead. But continue to use PyObject_Compare() for comparing the final (deciding) elements. - Align the comments in the type struct initializer. Note: I don't implement rich comparison for dictionaries -- there doesn't seem to be much to be gained. (The existing comparison already decides that shorter dicts are always smaller than longer dicts.)
2001-01-18 08:39:02 +08:00
(traverseproc)dict_traverse, /* tp_traverse */
(inquiry)dict_tp_clear, /* tp_clear */
SF patch #421922: Implement rich comparison for dicts. d1 == d2 and d1 != d2 now work even if the keys and values in d1 and d2 don't support comparisons other than ==, and testing dicts for equality is faster now (especially when inequality obtains).
2001-05-08 12:38:29 +08:00
dict_richcompare, /* tp_richcompare */
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
0, /* tp_weaklistoffset */
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
(getiterfunc)dict_iter, /* tp_iter */
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
0, /* tp_iternext */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
mapp_methods, /* tp_methods */
0, /* tp_members */
0, /* tp_getset */
0, /* tp_base */
0, /* tp_dict */
0, /* tp_descr_get */
0, /* tp_descr_set */
0, /* tp_dictoffset */
Make dictionary() a real constructor. Accepts at most one argument, "a mapping object", in the same sense dict.update(x) requires of x (that x has a keys() method and a getitem). Questionable: The other type constructors accept a keyword argument, so I did that here too (e.g., dictionary(mapping={1:2}) works). But type_call doesn't pass the keyword args to the tp_new slot (it passes NULL), it only passes them to the tp_init slot, so getting at them required adding a tp_init slot to dicts. Looks like that makes the normal case (i.e., no args at all) a little slower (the time it takes to call dict.tp_init and have it figure out there's nothing to do).
2001-09-02 16:22:48 +08:00
(initproc)dict_init, /* tp_init */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
PyType_GenericAlloc, /* tp_alloc */
dict_new, /* tp_new */
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
};
Got rid of all the last_name_* bogosities. I don't think the complexity saved much any more. A simple benchmark (grail) showed that there were 3 times as many misses as hits, and the same number of times again the code was bypassed altogether due to the existence of setattro/getattro.
1997-05-16 22:23:33 +08:00
/* For backward compatibility with old dictionary interface */
Quickly renamed the last directory.
1997-05-02 11:12:38 +08:00
PyObject *
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_GetItemString(PyObject *v, char *key)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Got rid of all the last_name_* bogosities. I don't think the complexity saved much any more. A simple benchmark (grail) showed that there were 3 times as many misses as hits, and the same number of times again the code was bypassed altogether due to the existence of setattro/getattro.
1997-05-16 22:23:33 +08:00
PyObject *kv, *rv;
kv = PyString_FromString(key);
if (kv == NULL)
return NULL;
rv = PyDict_GetItem(v, kv);
Py_DECREF(kv);
return rv;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_SetItemString(PyObject *v, char *key, PyObject *item)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Got rid of all the last_name_* bogosities. I don't think the complexity saved much any more. A simple benchmark (grail) showed that there were 3 times as many misses as hits, and the same number of times again the code was bypassed altogether due to the existence of setattro/getattro.
1997-05-16 22:23:33 +08:00
PyObject *kv;
int err;
kv = PyString_FromString(key);
if (kv == NULL)
Moved PyObject_{Get,Set}Attr to object.c. Fixed two 'return NULL' that should be 'return -1'.
1997-05-21 02:35:19 +08:00
return -1;
Don't intern the key string for getitem and delitem.
1997-09-30 07:31:11 +08:00
PyString_InternInPlace(&kv); /* XXX Should we really? */
Got rid of all the last_name_* bogosities. I don't think the complexity saved much any more. A simple benchmark (grail) showed that there were 3 times as many misses as hits, and the same number of times again the code was bypassed altogether due to the existence of setattro/getattro.
1997-05-16 22:23:33 +08:00
err = PyDict_SetItem(v, kv, item);
Py_DECREF(kv);
return err;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
int
Removed Py_PROTO and switched to ANSI C declarations in the dict implementation. This was really to test whether my new CVS+SSH setup is more usable than the old one -- and turns out it is (for whatever reason, it was impossible to do a commit before that involved more than one directory).
2000-07-05 01:44:48 +08:00
PyDict_DelItemString(PyObject *v, char *key)
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
{
Got rid of all the last_name_* bogosities. I don't think the complexity saved much any more. A simple benchmark (grail) showed that there were 3 times as many misses as hits, and the same number of times again the code was bypassed altogether due to the existence of setattro/getattro.
1997-05-16 22:23:33 +08:00
PyObject *kv;
int err;
kv = PyString_FromString(key);
if (kv == NULL)
Moved PyObject_{Get,Set}Attr to object.c. Fixed two 'return NULL' that should be 'return -1'.
1997-05-21 02:35:19 +08:00
return -1;
Got rid of all the last_name_* bogosities. I don't think the complexity saved much any more. A simple benchmark (grail) showed that there were 3 times as many misses as hits, and the same number of times again the code was bypassed altogether due to the existence of setattro/getattro.
1997-05-16 22:23:33 +08:00
err = PyDict_DelItem(v, kv);
Py_DECREF(kv);
return err;
Generalized version of dictionaries, with compatibility hacks.
1993-03-28 02:11:32 +08:00
}
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
/* Dictionary iterator type */
extern PyTypeObject PyDictIter_Type; /* Forward */
typedef struct {
PyObject_HEAD
dictobject *di_dict;
Mchael Hudson pointed out that the code for detecting changes in dictionary size was comparing ma_size, the hash table size, which is always a power of two, rather than ma_used, wich changes on each insertion or deletion. Fixed this.
2001-05-02 23:13:44 +08:00
int di_used;
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
int di_pos;
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
binaryfunc di_select;
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
} dictiterobject;
static PyObject *
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
dictiter_new(dictobject *dict, binaryfunc select)
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
{
dictiterobject *di;
di = PyObject_NEW(dictiterobject, &PyDictIter_Type);
if (di == NULL)
return NULL;
Py_INCREF(dict);
di->di_dict = dict;
Mchael Hudson pointed out that the code for detecting changes in dictionary size was comparing ma_size, the hash table size, which is always a power of two, rather than ma_used, wich changes on each insertion or deletion. Fixed this.
2001-05-02 23:13:44 +08:00
di->di_used = dict->ma_used;
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
di->di_pos = 0;
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
di->di_select = select;
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
return (PyObject *)di;
}
static void
dictiter_dealloc(dictiterobject *di)
{
Py_DECREF(di->di_dict);
PyObject_DEL(di);
}
static PyObject *
dictiter_next(dictiterobject *di, PyObject *args)
{
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
PyObject *key, *value;
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
Mchael Hudson pointed out that the code for detecting changes in dictionary size was comparing ma_size, the hash table size, which is always a power of two, rather than ma_used, wich changes on each insertion or deletion. Fixed this.
2001-05-02 23:13:44 +08:00
if (di->di_used != di->di_dict->ma_used) {
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
PyErr_SetString(PyExc_RuntimeError,
"dictionary changed size during iteration");
return NULL;
}
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
if (PyDict_Next((PyObject *)(di->di_dict), &di->di_pos, &key, &value)) {
return (*di->di_select)(key, value);
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
}
PyErr_SetObject(PyExc_StopIteration, Py_None);
return NULL;
}
static PyObject *
dictiter_getiter(PyObject *it)
{
Py_INCREF(it);
return it;
}
static PyMethodDef dictiter_methods[] = {
{"next", (PyCFunction)dictiter_next, METH_VARARGS,
"it.next() -- get the next value, or raise StopIteration"},
{NULL, NULL} /* sentinel */
};
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
static PyObject *dictiter_iternext(dictiterobject *di)
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
{
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
PyObject *key, *value;
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
Mchael Hudson pointed out that the code for detecting changes in dictionary size was comparing ma_size, the hash table size, which is always a power of two, rather than ma_used, wich changes on each insertion or deletion. Fixed this.
2001-05-02 23:13:44 +08:00
if (di->di_used != di->di_dict->ma_used) {
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
PyErr_SetString(PyExc_RuntimeError,
"dictionary changed size during iteration");
return NULL;
}
Add experimental iterkeys(), itervalues(), iteritems() to dict objects. Tests show that iteritems() is 5-10% faster than iterating over the dict and extracting the value with dict[key].
2001-05-01 20:10:21 +08:00
if (PyDict_Next((PyObject *)(di->di_dict), &di->di_pos, &key, &value)) {
return (*di->di_select)(key, value);
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
}
return NULL;
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
}
PyTypeObject PyDictIter_Type = {
PyObject_HEAD_INIT(&PyType_Type)
0, /* ob_size */
"dictionary-iterator", /* tp_name */
sizeof(dictiterobject), /* tp_basicsize */
0, /* tp_itemsize */
/* methods */
(destructor)dictiter_dealloc, /* tp_dealloc */
0, /* tp_print */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
0, /* tp_getattr */
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
0, /* tp_setattr */
0, /* tp_compare */
0, /* tp_repr */
0, /* tp_as_number */
0, /* tp_as_sequence */
0, /* tp_as_mapping */
0, /* tp_hash */
0, /* tp_call */
0, /* tp_str */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
PyObject_GenericGetAttr, /* tp_getattro */
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
0, /* tp_setattro */
0, /* tp_as_buffer */
Py_TPFLAGS_DEFAULT, /* tp_flags */
0, /* tp_doc */
0, /* tp_traverse */
0, /* tp_clear */
0, /* tp_richcompare */
0, /* tp_weaklistoffset */
(getiterfunc)dictiter_getiter, /* tp_iter */
Mondo changes to the iterator stuff, without changing how Python code sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
2001-04-23 22:08:49 +08:00
(iternextfunc)dictiter_iternext, /* tp_iternext */
Merge of descr-branch back into trunk.
2001-08-02 12:15:00 +08:00
dictiter_methods, /* tp_methods */
0, /* tp_members */
0, /* tp_getset */
0, /* tp_base */
0, /* tp_dict */
0, /* tp_descr_get */
0, /* tp_descr_set */
Iterators phase 1. This comprises: new slot tp_iter in type object, plus new flag Py_TPFLAGS_HAVE_ITER new C API PyObject_GetIter(), calls tp_iter new builtin iter(), with two forms: iter(obj), and iter(function, sentinel) new internal object types iterobject and calliterobject new exception StopIteration new opcodes for "for" loops, GET_ITER and FOR_ITER (also supported by dis.py) new magic number for .pyc files new special method for instances: __iter__() returns an iterator iteration over dictionaries: "for x in dict" iterates over the keys iteration over files: "for x in file" iterates over lines TODO: documentation test suite decide whether to use a different way to spell iter(function, sentinal) decide whether "for key in dict" is a good idea use iterators in map/filter/reduce, min/max, and elsewhere (in/not in?) speed tuning (make next() a slot tp_next???)
2001-04-21 03:13:02 +08:00
};
Reference in New Issue Copy Permalink