The title of howto/cporting.rst is "Porting Extension Modules To 3.0".  It then talks about 3.0 in a whole bunch of places.  Considering that we're working on 3.3, and considering that 3.0 is end-of-lifed (not even meriting a branch in hg), wouldn't it be better for the document to talk about "3.x"?  It already talks about "2.x" in several places, so it's not like this would confuse the reader.

Alternatively, we could remove the ".0" (and maybe the ".x"s) so the document talks about porting from "Python 2" to "Python 3".

I'd be happy to make the patch / check in the change.

Why shouldn't I check this in to the 2.7 / 3.1 branches?

3.1 because it won't have any effect; it's in security-fix mode.

For 2.7 go ahead.

I like "Python 2" more than "2.x".

Yes, 'to Python 3'. Patch welcome. I would make it up to date as of 3.2. For 3.3, the Unicode api will change (grow) but that has not been finalized yet.

+1 ;)

Attached is my first revision patch.  I did some other editing for
clarity / 80 columns, though I can back those out from this patch (and put in another) if that's best.

Patch is against the 2.7 branch; once this goes in I'll port all my recent cporting.rst changes to 3.2 and trunk.

> Attached is my first revision patch.

LGTM

> I did some other editing for clarity / 80 columns, though I can back 
> those out from this patch (and put in another) if that's best.

That's fine with me, and while you are at it, you could fix this too when you commit:
+   the many Python level changes made leaving Python 2's API intact
s/Python level/Python-level/

> Patch is against the 2.7 branch; once this goes in I'll port all my 
> recent cporting.rst changes to 3.2 and trunk.

Remember to convert things like :cmacro: to :c:macro: when you port it.

Gah!  This one fell through the cracks.

Attached is an updated patch with Ezio's "Python-level" fix, and a little more paragraph tidying.  (Apart from that one   ^ dash, the only changes
between r1 and r2 are eols.)

Unless I hear otherwise, I'll check this in to 2.7 on Tuesday or so.   Then I'll manually edit the 3.2 docs to match, and once that goes in I'll forward-merge into trunk.

Note that the 2.7 docs now use a recent Sphinx too, so :c:macro: should work on all the 3 branches (so you don't have to use :cmacro: on 2.7 and :c:macro: on 3.x).

Whoops--I hadn't updated my repo since last year, and someone had already changed to :c:macro:, :c:func:, and :c:type:.  When will I learn!

Attached is a new diff with those changes, against revision @4c6662090870 (on the 2.7 branch).  Also, while I was in there, I made some minor edits to the start of the paragraph about "long/int Unification".  I think it's a slight improvement.

+can simply switch to :c:type:`Capsule`.  If you need to support Python 3.0,
+or versions of Python earlier than 2.7,
+you'll have to support both CObjects and Capsules.

We pretend that Python 3.0 never existed, or was a beta.  Python 3.1 is the first supported 3.x release.  Thus I think you can delete that mention.

New changeset eb88cc90cc56 by Larry Hastings in branch '2.7':
Issue #13086: Update howto/cporting.rst to discuss "Python 3" instead of "3.0".
http://hg.python.org/cpython/rev/eb88cc90cc56

@eric.araujo: I talked to Brett about it.  We don't pretend that Python 3.0 never existed; we tell people it's unsupported and unsuitable for production use.  At his suggestion I added a statement to that effect, and left the rest the same.

I'll now manually incorporate this into the 3.2 branch, then forward-port to trunk.

New changeset 28849d00a41e by Larry Hastings in branch '3.2':
Propagate changes for issues #13053 and #13086 from 2.7 to 3.2.  (Doc only.)
http://hg.python.org/cpython/rev/28849d00a41e

New changeset c316e8a4a5e2 by Larry Hastings in branch 'default':
Merge: Propagate changes for issues #13053 and #13086 from 2.7 to 3.2.
http://hg.python.org/cpython/rev/c316e8a4a5e2

Now checked in to 2.7, 3.2, and default.  Thanks everyone!