version of PySlice_GetIndicesEx"):
> OK. Michael, if you want to check in indices(), go ahead.
Then I did what was needed, but didn't check it in. Here it is.
[ 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.
Rewrote the subsection on coercion rules (and made it a proper
subsection, with a label). The new section is much less precise,
because precise rules would be too hard to give (== I don't know what
they are any more :-). OTOH, the new section gives much more
up-to-date information.
Also noted that __coerce__ may return NotImplemented, with the same
meaning as None.
I beg Fred forgiveness: my use of \code{} is probably naive. Please
fix this and other markup nits. An index entry would be nice.
This could be a 2.2 bugfix candidate, if we bother about old docs
(Fred?)
PEP 285. Everything described in the PEP is here, and there is even
some documentation. I had to fix 12 unit tests; all but one of these
were printing Boolean outcomes that changed from 0/1 to False/True.
(The exception is test_unicode.py, which did a type(x) == type(y)
style comparison. I could've fixed that with a single line using
issubtype(x, type(y)), but instead chose to be explicit about those
places where a bool is expected.
Still to do: perhaps more documentation; change standard library
modules to return False/True from predicates.
Split the description of co_flags into two paragraphs. The first
describes the flags that are used for non-future purposes, where
CO_GENERATOR was added. The second describes __future__'s use of
co_flags and mentions the only one currently meaningful,
CO_FUTURE_DIVISION.
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.
as container objects rather than as mapping objects (in the index entries).
Change the section heading and intro sentence to be a little more general,
since that's how things have actually evolved.
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.
Add new opcodes LOAD_CLOSURE, LOAD_DEREF, STORE_DEREF, MAKE_CLOSURE to
docs for dis module.
Add docs for new function and code members in Sec. 3 of ref manual.
They're present regardless of whether nested scopes are used.
Remove description of default argument hack from Sec. 7 of the ref
manual and refer the reader to the appendix.
supported as of Python 2.1. We still need to
have an entry for this since it is reasonable
for users to want to understand existing code.
This closes SF bug #122715.
Show how code can be written to handle __getslice__ & friends in a way that
is compatible with pre-2.0 versions of Python while still working with the
"new" way of handling slicing.
Additional explanation added by Fred Drake.
This closes SourceForge patch #101388.
is no __getslice__ available. Also does the same for C extension types.
Includes rudimentary documentation (it could use a cross reference to the
section on slice objects, I couldn't figure out how to do that) and a test
suite for all Python __hooks__ I could think of, including the new
behaviour.
distutils patches, which I'll leave to the distutils maintainers.
Tip: review the patch like this:
grep "^[\!+-] " <patchfile>
To get a quick and easy way to review the actual changes. Most of the
changes are single-line ones, anyway.
are and are not turned into bound methods; some confusion was noted by
Andrew Dalke.
In particular, it has to be noted that functions located on the class
instance are not turned into any sort of method, only those which are
found via the underlying class.