[ 400998 ] experimental support for extended slicing on lists
somewhat spruced up and better tested than it was when I wrote it.
Includes docs & tests. The whatsnew section needs expanding, and arrays
should support extended slices -- later.
don't understand how this function works, also beefed up the docs. The
most common usage error is of this form (often spread out across gotos):
if (_PyString_Resize(&s, n) < 0) {
Py_DECREF(s);
s = NULL;
goto outtahere;
}
The error is that if _PyString_Resize runs out of memory, it automatically
decrefs the input string object s (which also deallocates it, since its
refcount must be 1 upon entry), and sets s to NULL. So if the "if"
branch ever triggers, it's an error to call Py_DECREF(s): s is already
NULL! A correct way to write the above is the simpler (and intended)
if (_PyString_Resize(&s, n) < 0)
goto outtahere;
Bugfix candidate.
(The real issue is whether modules can benefit from an alternate
implementation strategy rather than using a dictionary. We should migrate
away from direct dictionary manipulation to allow more room for Jeremy to
flex the implementation with changes in globals lookup.)
document to the C API reference. Move some instructional text from the API
reference to the Extending & Embedding manual.
Fix the descriptions of the es and es# formats for PyArg_Parse*().
This closes SF bug #536516.
descriptor, as used for the tp_methods slot of a type. These new flag
bits are both optional, and mutually exclusive. Most methods will not
use either. These flags are used to create special method types which
exist in the same namespace as normal methods without having to use
tedious construction code to insert the new special method objects in
the type's tp_dict after PyType_Ready() has been called.
If METH_CLASS is specified, the method will represent a class method
like that returned by the classmethod() built-in.
If METH_STATIC is specified, the method will represent a static method
like that returned by the staticmethod() built-in.
These flags may not be used in the PyMethodDef table for modules since
these special method types are not meaningful in that case; a
ValueError will be raised if these flags are found in that context.
PyDict_UpdateFromSeq2(): removed it.
PyDict_MergeFromSeq2(): made it public and documented it.
PyDict_Merge() docs: updated to reveal <wink> that the second
argument can be any mapping object.
parameters (like \UNIX) are commonly entered using an empty group to
separate the markup from a following inter-word space; this is not
needed when the next character is punctuation, or the markup is the
last thing in the enclosing group. These cases were marked
inconsistently; the empty group is now *only* used when needed.
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).
has grown beyond what font-lock will work with using the default (X)Emacs
settings.
Indentation of the description has been made consistent, and a number of
smaller markup adjustments have been made as well.
introduced in Python 2.2.
Add documentation for the slice object interface (not complete).
Added version annotations for several of the Python 2.2 APIs already
documented.
Moved the PyArg_Parse*(), Py_BuildValue() functions to the Utilities
chapter, added a minimal description and reference to the Extending
manual for Py_BuildValue().
PyObject_InitVar(), PyObject_Del(), PyObject_NEW(),
PyObject_NEW_VAR(), and PyObject_DEL().
Add notes to PyMem_Malloc() and PyMem_New() about the memory buffers
not being initialized.
This fixes SF bug #439012.
Added explicit return value information for PyList_SetItem(),
PyDict_SetItem(), and PyDict_SetItemString(). Corrected return type
for PyList_SET_ITEM().
Fixed index entries in the descriptions of PyLong_AsLong() and
PyLong_AsUnignedLong().
This fixes the API manual portion of SF bug #440037.
Note that the headers properly declare everything as 'extern "C"' for
C++ users.
Document _Py_NoneStruct.
Added links to the Extending & Embedding manual for PyArg_ParseTuple()
and PyArg_ParseTupleAndKeywords().
Added note that PyArg_Parse() should not be used in new code.
Fix up a few style nits -- avoid "e.g." and "i.e." -- these make
translation more difficult, as well as reading the English more
difficult for non-native speakers.
PySequence_Size(), not PyObject_Size(): the later considers the mapping
methods as well as the sequence methods, which is not needed here. Either
should be equally fast in this case, but PySequence_Size() offers a better
conceptual match.
Added information on PyIter_Check(), PyIter_Next(),
PyObject_Unicode(), PyString_AsDecodedObject(),
PyString_AsEncodedObject(), and PyThreadState_GetDict().
state *which* other function the current one is like, even if the
descriptions are adjacent.
Revise the _PyTuple_Resize() description to reflect the removal of the
third parameter.
and introduces a new method .decode().
The major change is that strg.encode() will no longer try to convert
Unicode returns from the codec into a string, but instead pass along
the Unicode object as-is. The same is now true for all other codec
return types. The underlying C APIs were changed accordingly.
Note that even though this does have the potential of breaking
existing code, the chances are low since conversion from Unicode
previously took place using the default encoding which is normally
set to ASCII rendering this auto-conversion mechanism useless for
most Unicode encodings.
The good news is that you can now use .encode() and .decode() with
much greater ease and that the door was opened for better accessibility
of the builtin codecs.
As demonstration of the new feature, the patch includes a few new
codecs which allow string to string encoding and decoding (rot13,
hex, zip, uu, base64).
Written by Marc-Andre Lemburg. Copyright assigned to the PSF.
patch for sharing single character Unicode objects.
Martin's patch had to be reworked in a number of ways to take Unicode
resizing into consideration as well. Here's what the updated patch
implements:
* Single character Unicode strings in the Latin-1 range are shared
(not only ASCII chars as in Martin's original patch).
* The ASCII and Latin-1 codecs make use of this optimization,
providing a noticable speedup for single character strings. Most
Unicode methods can use the optimization as well (by virtue
of using PyUnicode_FromUnicode()).
* Some code cleanup was done (replacing memcpy with Py_UNICODE_COPY)
* The PyUnicode_Resize() can now also handle the case of resizing
unicode_empty which previously resulted in an error.
* Modified the internal API _PyUnicode_Resize() and
the public PyUnicode_Resize() API to handle references to
shared objects correctly. The _PyUnicode_Resize() signature
changed due to this.
* Callers of PyUnicode_FromUnicode() may now only modify the Unicode
object contents of the returned object in case they called the API
with NULL as content template.
Note that even though this patch passes the regression tests, there
may still be subtle bugs in the sharing code.
except that it always returns Unicode objects.
A new C API PyObject_Unicode() is also provided.
This closes patch #101664.
Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.
Python equivalent actually equivalent to the C code. Also, in the C code,
place the "goto" statements on a line by themselves for better visibility
of statements that affect control flow.
This closes bug #123398.
and PyString_AsStringAndSize() for strings that were just created using
PyString_FromStringAndSize(NULL, n).
This closes bug #117377.
Added warning about passing NULL to the concrete object functions; many of
them use the appropriate Py<Type>_Check() test, but do not check for NULL.
"de-allocated" --> "deallocated"
which implements the automatic conversion from Unicode to a string
object using the default encoding.
The new API is then put to use to have eval() and exec accept
Unicode objects as code parameter. This closes bugs #110924
and #113890.
As side-effect, the traditional C APIs PyString_Size() and
PyString_AsString() will also accept Unicode objects as
parameters.
Here are some changes to the C API docs. The memory examples & API have
been updated because one malloc family is gone (Py_Malloc).
You'll see other small additions to the "building new types" section
for completeness and some cleanup at the end of the memory section.
by Edward K. Ream <edream@users.sourceforge.net> about FILE* values and
incompatible C libraries in dynamically linked extensions. It is not clear
(to me) how realistic the issue is, but it is better documented than not.
This closes SourceForge bug #111520.
PyRun_InteractiveLoop(): Added descriptions.
PyExc_WindowsError: Added to list of standard exceptions and added note
about the right preprocessor symbol to use to protect
code that uses it.
Added a bit more documentation in the chapter on building extension types,
including Py_FindMethod() documentation.
Several minor consistency nits were fixed.
Fix typo in a C code example: KeyError is spelled PyExc_KeyError in C; the
"K" is upper case!
Some index entries.
On function signatures, always use parameter names. Make return types match
what's in the header files. When the return type is a pointer, always omit
the space between te type name and the "*"; leaving it in results in
type * func(..)
and having two spaces there just looks terrible.
now requires LaTeX2HTML 98.1p1 or newer (& and is still in progress).
This means that doing things to change the formatting of the manuals (at the
"normal user" level, like A4 paper), can happen in just one place, rather
than in each document file.
Use \emph{} when referring to title of any of the Python manuals, like is
done in the other manuals.
In some places, use \emph{} or \dfn{} instead of ``...''.
Use \samp{} instead of \code{} when marking identifier prefixes.
Use logical markup wherever it made sense.
Fixed a bunch of typos.
In several places, use "---" instead of "--" to get the emdash.
Start sentences with capital letters and end them with periods, as needed.
"it's" --> "its" in many places: "it's" it *always* a contraction of "it is",
and "its" should always be used for the possessive.
"don't" --> "doesn't"
"should discards any" --> "should discard any"
In C function descriptions, use \var{} to mark parameters in the running
text instead of \code{}. This matches usage in the other manauls better,
and is more consistent with the formatting of the function signatures.
Lots of little changes to implement this.
Lots of fixups needed due to appearant heavy cut-&-paste in the orignal
document.
Mention that the exception objects may be either classes or strings,
depending on the use of -X; they were unequivocally stated to be strings
in the section "Standard Exceptions".
"mkvalue()" --> "Py_BuildValue()"
Description of PyNumber_Power() indicates that the third value is option,
but not how to indicate that it was omitted. Clarified.
Explain the behavior of PyString_FromStringAndSize() if the buffer is NULL.
Explain the Py_complex structure a little (tell what it's used for) and use
a {verbatim} environment for the structure definition itself.
Fix explanation of PyFile_SoftSpace().
Update the example version string to 1.5.
Combined the sections on defining new object types.
gave the return type as part of the function field and used an empty return
type field. Fixed.
Function name field for PyLong_FromString() included an asterisk at the
beginning of the function name field; removed.
Fred Drake
Thomas Heller
Michael W. Hudson
Guido van Rossum
Martin v. Löwis
Tim Peters
Skip Montanaro
Neil Schemenauer
Jeremy Hylton
Greg Ward
Barry Warsaw
Thomas Wouters
Marc-André Lemburg
Greg Stein
Moshe Zadka
Andrew M. Kuchling