| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of some of the common builtin types.
Use a bit in tp_flags for each common builtin type. Check the bit
to determine if any instance is a subclass of these common types.
The check avoids a function call and O(n) search of the base classes.
The check is done in the various Py*_Check macros rather than calling
PyType_IsSubtype().
All the bits are set in tp_flags when the type is declared
in the Objects/*object.c files because PyType_Ready() is not called
for all the types. Should PyType_Ready() be called for all types?
If so and the change is made, the changes to the Objects/*object.c files
can be reverted (remove setting the tp_flags). Objects/typeobject.c
would also have to be modified to add conditions
for Py*_CheckExact() in addition to each the PyType_IsSubtype check.
|
| |
|
| |
|
| |
|
|
|
|
| |
the tuple isn't used as the "exception arguments tuple".
|
|
|
|
|
|
| |
loops are, um, infinite. These conditions should not be able to happen.
Will backport.
|
| |
|
| |
|
| |
|
|
|
|
| |
PyThreadState_GET() complains if the tstate is NULL, but only in debug mode.
|
|
|
|
|
|
|
|
| |
he didn't know this), so merged in some changes I made during
review. Nothing material apart from changing a new `mask` local
from int to Py_ssize_t. Mostly this is repairing comments that
were made incorrect, and adding new comments. Also a few
minor code rewrites for clarity or helpful succinctness.
|
|
|
|
| |
[ 1456209 ] dictresize() vulnerability ( <- backport candidate ).
|
|
|
|
|
|
| |
our lives taking turns rewriting code that works ;-),
get rid of casting illusions by declaring a new variable
with the obvious type.
|
|
|
|
| |
from a (possibly) wider variable.
|
|
|
|
| |
Py_ReprEntr returns an int
|
|
|
|
| |
in comment
|
| |
|
|
|
|
|
|
| |
I don't have a box with nearly enough RAM, or an OS,
that could get close to tickling this, though (requires
a dict w/ at least 2**31 entries).
|
|
|
|
|
|
|
|
| |
using a custom, nearly-identical macro. This probably changes how some of
these functions are compiled, which may result in fractionally slower (or
faster) execution. Considering the nature of traversal, visiting much of the
address space in unpredictable patterns, I'd argue the code readability and
maintainability is well worth it ;P
|
|
|
|
| |
in dicts and sets when computing the total number of references.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- The copy module now "copies" function objects (as atomic objects).
- dict.__getitem__ now looks for a __missing__ hook before raising
KeyError.
- Added a new type, defaultdict, to the collections module.
This uses the new __missing__ hook behavior added to dict (see above).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
http://mail.python.org/pipermail/python-dev/2006-February/060524.html
|
|
|
|
| |
no code changes.
|
| |
|
| |
|
|
|
|
| |
(Contributed by Barry Warsaw and Matt Messier.)
|
| |
|
| |
|
|
|
|
| |
modules and objects.
|
| |
|
| |
|
|
|
|
|
|
| |
* Document the differences between them
* Fix corner cases covered by the unittests
* Use Py_RETURN_NONE where possible for dictionaries
|
|
|
|
|
|
| |
necessarily always set before used. Between Tim, Armin & me we
couldn't prove GCC wrong, so we decided to fix the algorithm. This
version is Armin's.
|
| |
|
|
|
|
|
|
| |
This gives another 30% speedup for operations such as
map(func, d.iteritems()) or list(d.iteritems()) which can both take
advantage of length information when provided.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Split into three separate types that share everything except the
code for iternext. Saves run time decision making and allows
each iternext function to be specialized.
* Inlined PyDict_Next(). In addition to saving a function call, this
allows a redundant test to be eliminated and further specialization
of the code for the unique needs of each iterator type.
* Created a reusable result tuple for iteritems(). Saves the malloc
time for tuples when the previous result was not kept by client code
(this is the typical use case for iteritems). If the client code
does keep the reference, then a new tuple is created.
Results in a 20% to 30% speedup depending on the size and sparsity
of the dictionary.
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Factored constant structure references out of the inner loops for
PyDict_Next(), dict_keys(), dict_values(), and dict_items().
Gave measurable speedups to each (the improvement varies depending
on the sparseness of the dictionary being measured).
* Added a freelist scheme styled after that for tuples. Saves around
80% of the calls to malloc and free. About 10% of the time, the
previous dictionary was completely empty; in those cases, the
dictionary initialization with memset() can be skipped.
|
| |
|
|
|
|
|
|
|
|
| |
(Championed by Bob Ippolito.)
The update() method for mappings now accepts all the same argument forms
as the dict() constructor. This includes item lists and/or keyword
arguments.
|
|
|
|
|
| |
This change probably isn't work a bug fix. It's unlikely that anyone
was calling this method without passing it a real dict.
|
| |
|
|
|
|
|
| |
* Used the flag to optimize set.__contains__(), dict.__contains__(),
dict.__getitem__(), and list.__getitem__().
|
|
|
|
|
|
|
| |
than PySequence_Contains() and more clearly applicable to dicts.
Apply the new function in setobject.c where __contains__ checking is
ubiquitous.
|
|
|
|
| |
(Contributed by George Yoshida.)
|