summaryrefslogtreecommitdiffstats
path: root/Include
diff options
context:
space:
mode:
authorTim Peters <tim.peters@gmail.com>2001-10-26 05:06:50 (GMT)
committerTim Peters <tim.peters@gmail.com>2001-10-26 05:06:50 (GMT)
commit1fc240e85150f5cb39502a87cc9a4a0a8cbe5ab0 (patch)
treed764262205e36bcc61e7cb42895236fdca67c9d3 /Include
parentb016da3b8391b7401afd95f2c90f5073976c475b (diff)
downloadcpython-1fc240e85150f5cb39502a87cc9a4a0a8cbe5ab0.zip
cpython-1fc240e85150f5cb39502a87cc9a4a0a8cbe5ab0.tar.gz
cpython-1fc240e85150f5cb39502a87cc9a4a0a8cbe5ab0.tar.bz2
Generalize dictionary() to accept a sequence of 2-sequences. At the
outer level, the iterator protocol is used for memory-efficiency (the outer sequence may be very large if fully materialized); at the inner level, PySequence_Fast() is used for time-efficiency (these should always be sequences of length 2). dictobject.c, new functions PyDict_{Merge,Update}FromSeq2. These are wholly analogous to PyDict_{Merge,Update}, but process a sequence-of-2- sequences argument instead of a mapping object. For now, I left these functions file static, so no corresponding doc changes. It's tempting to change dict.update() to allow a sequence-of-2-seqs argument too. Also changed the name of dictionary's keyword argument from "mapping" to "x". Got a better name? "mapping_or_sequence_of_pairs" isn't attractive, although more so than "mosop" <wink>. abstract.h, abstract.tex: Added new PySequence_Fast_GET_SIZE function, much faster than going thru the all-purpose PySequence_Size. libfuncs.tex: - Document dictionary(). - Fiddle tuple() and list() to admit that their argument is optional. - The long-winded repetitions of "a sequence, a container that supports iteration, or an iterator object" is getting to be a PITA. Many months ago I suggested factoring this out into "iterable object", where the definition of that could include being explicit about generators too (as is, I'm not sure a reader outside of PythonLabs could guess that "an iterator object" includes a generator call). - Please check my curly braces -- I'm going blind <0.9 wink>. abstract.c, PySequence_Tuple(): When PyObject_GetIter() fails, leave its error msg alone now (the msg it produces has improved since PySequence_Tuple was generalized to accept iterable objects, and PySequence_Tuple was also stomping on the msg in cases it shouldn't have even before PyObject_GetIter grew a better msg).
Diffstat (limited to 'Include')
-rw-r--r--Include/abstract.h12
1 files changed, 8 insertions, 4 deletions
diff --git a/Include/abstract.h b/Include/abstract.h
index d736efc..351149d 100644
--- a/Include/abstract.h
+++ b/Include/abstract.h
@@ -951,26 +951,30 @@ xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*/
DL_IMPORT(PyObject *) PySequence_List(PyObject *o);
-
/*
Returns the sequence, o, as a list on success, and NULL on failure.
This is equivalent to the Python expression: list(o)
*/
DL_IMPORT(PyObject *) PySequence_Fast(PyObject *o, const char* m);
-
/*
Returns the sequence, o, as a tuple, unless it's already a
tuple or list. Use PySequence_Fast_GET_ITEM to access the
- members of this list.
+ members of this list, and PySequence_Fast_GET_SIZE to get its length.
Returns NULL on failure. If the object does not support iteration,
raises a TypeError exception with m as the message text.
*/
+#define PySequence_Fast_GET_SIZE(o) \
+ (PyList_Check(o) ? PyList_GET_SIZE(o) : PyTuple_GET_SIZE(o))
+ /*
+ Return the size of o, assuming that o was returned by
+ PySequence_Fast and is not NULL.
+ */
+
#define PySequence_Fast_GET_ITEM(o, i)\
(PyList_Check(o) ? PyList_GET_ITEM(o, i) : PyTuple_GET_ITEM(o, i))
-
/*
Return the ith element of o, assuming that o was returned by
PySequence_Fast, and that i is within bounds.