* add expansion of default values in help text: the string
"%default" in an option's help string is expanded to str() of
that option's default value, or "none" if no default value.
* bug #955889: option default values that happen to be strings are
now processed in the same way as values from the command line; this
allows generation of nicer help when using custom types. Can
be disabled with parser.set_process_default_values(False).
* bug #960515: don't crash when generating help for callback
options that specify 'type', but not 'dest' or 'metavar'.
* feature #815264: change the default help format for short options
that take an argument from e.g. "-oARG" to "-o ARG"; add
set_short_opt_delimiter() and set_long_opt_delimiter() methods to
HelpFormatter to allow (slight) customization of the formatting.
* patch #736940: internationalize Optik: all built-in user-
targeted literal strings are passed through gettext.gettext(). (If
you want translations (.po files), they're not included with Python
-- you'll find them in the Optik source distribution from
http://optik.sourceforge.net/ .)
* bug #878453: respect $COLUMNS environment variable for
wrapping help output.
* feature #988122: expand "%prog" in the 'description' passed
to OptionParser, just like in the 'usage' and 'version' strings.
(This is *not* done in the 'description' passed to OptionGroup.)
impossible to remember, so renamed one to something obvious. Headed
off potential signed-vs-unsigned compiler complaints I introduced by
changing the type of a vrbl to unsigned. Removed the need for the
tedious explanation about "backward pointer loops" by looping on an
int instead.
result.
list_resize(): Document the intent. Code is increasingly relying on
subtle aspects of its behavior, and they deserve to be spelled out.
list_ass_slice(): A bit more simplification, by giving it a common
error exit and initializing more values.
Be clearer in comments about what "size" means (# of elements? # of
bytes?).
While the number of elements in a list slice must fit in an int, there's
no guarantee that the number of bytes occupied by the slice will. That
malloc() and memmove() take size_t arguments is a hint about that <wink>.
So changed to use size_t where appropriate.
ihigh - ilow should always be >= 0, but we never asserted that. We do
now.
The loop decref'ing the recycled slice had a subtle insecurity: C doesn't
guarantee that a pointer one slot *before* an array will compare "less
than" to a pointer within the array (it does guarantee that a pointer
one beyond the end of the array compares as expected). This was actually
an issue in KSR's C implementation, so isn't purely theoretical. Python
probably has other "go backwards" loops with a similar glitch.
list_clear() is OK (it marches an integer backwards, not a pointer).
though I tried to be very careful. This is a slight simplification, and it
adds a new feature: a small stack-allocated "recycled" array for the cases
when we don't remove too many items.
It allows PyList_SetSlice() to never fail if:
* you are sure that the object is a list; and
* you either do not remove more than 8 items, or clear the list.
This makes a number of other places in the source code correct again -- there
are some places that delete a single item without checking for MemoryErrors
raised by PyList_SetSlice(), or that clear the whole list, and sometimes the
context doesn't allow an error to be propagated.
invariants allows the ob_item != NULL check to be replaced with an
assertion.
* Added assertions to list_init() which document and verify that the
tp_new slot establishes the invariants. This may preclude a future
bug if a custom tp_new slot is written.
to NULL during the lifetime of the object.
* listobject.c nevertheless did not conform to the other invariants,
either; fixed.
* listobject.c now uses list_clear() as the obvious internal way to clear
a list, instead of abusing list_ass_slice() for that. It makes it easier
to enforce the invariant about ob_item == NULL.
* listsort() sets allocated to -1 during sort; any mutation will set it
to a value >= 0, so it is a safe way to detect mutation. A negative
value for allocated does not cause a problem elsewhere currently.
test_sort.py has a new test for this fix.
* listsort() leak: if items were added to the list during the sort, AND if
these items had a __del__ that puts still more stuff into the list,
then this more stuff (and the PyObject** array to hold them) were
overridden at the end of listsort() and never released.
mutation during list.sort() used to rely on that listobject.c always
NULL'ed ob_item when ob_size fell to 0. That's no longer true, so the
test for list mutation during a sort is no longer reliable. Changed the
test to rely instead on that listobject.c now never NULLs-out ob_item
after (if ever) ob_item gets a non-NULL value. This new assumption is
also documented now, as a required invariant in listobject.h.
The new assumption allowed some real simplification to some of the
hairier code in listsort(), so is a Good Thing on that count.
Greg Ward
Tim Peters
Fred Drake
Martin v. Löwis
Armin Rigo
Raymond Hettinger
Vinay Sajip
Neal Norwitz
Skip Montanaro
Thomas Heller
Marc-André Lemburg
Andrew M. Kuchling
Hye-Shik Chang