New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update howto/cporting.rst so it talks about Python 3 instead of 3.0 #57295
Comments
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 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. |
LGTM
That's fine with me, and while you are at it, you could fix this too when you commit:
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 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, 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': |
@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': |
New changeset c316e8a4a5e2 by Larry Hastings in branch 'default': |
Now checked in to 2.7, 3.2, and default. Thanks everyone! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: