Reference to http://www.unicode.org/Public/6.0.0/ucd/extracted/DerivedNumericType.txt in http://docs.python.org/3.4/library/stdtypes.html#numeric-types-int-float-complex should be changed to http://www.unicode.org/Public/6.1.0/ucd/extracted/DerivedNumericType.txt for 3.3 and to http://www.unicode.org/Public/6.2.0/ucd/extracted/DerivedNumericType.txt for 3.4.

Note that the change from 6.1 to 6.2 is immaterial because it did not involve the Nd category, but a change from 6.0 to 6.1 introduced several new ranges:

+110F0..110F9  ; Decimal # Nd  [10] SORA SOMPENG DIGIT ZERO..SORA SOMPENG DIGIT NINE
+11136..1113F  ; Decimal # Nd  [10] CHAKMA DIGIT ZERO..CHAKMA DIGIT NINE
+111D0..111D9  ; Decimal # Nd  [10] SHARADA DIGIT ZERO..SHARADA DIGIT NINE
+116C0..116C9  ; Decimal # Nd  [10] TAKRI DIGIT ZERO..TAKRI DIGIT NINE

This is a trivial change, but I would like someone to review this in case there is a better solution to keep this in sync with unicodedata.unidata_version.

If all the versions are up to date it shouldn't be difficult to grep for '6.2.0' at the next update, and I would expect people to do it when it happens.  Maybe adding a comment where unidata_version is defined as a remainder to update the rest will suffice.

That said there might be some rst trick to define constants and use them around but I don't know it off the top of my head and if there is, I'm not sure it can be used in links.

Here is what grep revealed:

$ find Doc -name \*.rst | xargs grep -n '6\.2\.0'
Doc/library/stdtypes.rst:357:   See http://www.unicode.org/Public/6.2.0/ucd/extracted/DerivedNumericType.txt
Doc/library/unicodedata.rst:18:this database is compiled from the `UCD version 6.2.0
Doc/library/unicodedata.rst:19:<http://www.unicode.org/Public/6.2.0/ucd>`_.
Doc/library/unicodedata.rst:169:.. [#] http://www.unicode.org/Public/6.2.0/ucd/NameAliases.txt
Doc/library/unicodedata.rst:171:.. [#] http://www.unicode.org/Public/6.2.0/ucd/NamedSequences.txt

I added a note next to UNIDATA_VERSION = "6.2.0" in makeunicodedata.py script. The makeunicodedata.py would be a place to put code that would update the docs automatically, but with only two affected files I don't think this is worth the effort.  Chances are at least unicodedata.rst will benefit from a manual review to reflect any substantive changes in the UCD.

I have found another place where explicit UCD version is used in the docs:

Doc/reference/lexical_analysis.rst:729:.. [#] http://www.unicode.org/Public/6.1.0/ucd/NameAliases.txt

I am not sure how this case should be handled.  The language reference was deliberately written so that it avoids mentioning specific version of Unicode.  For example, PropList.txt in the "Identifiers and keywords" section is linked to the location of the latest published PropList.txt: <http://unicode.org/Public/UNIDATA/PropList.txt>.  This means that as of today, all versions of documentation (3.0 through 3.4) refere to Unicode 6.2.0 version of this file.  This may be misleading for the users of the older python versions.

In the same section, there is a reference top a "non-normative HTML file listing all valid identifier characters for Unicode 4.1."

I would suggest that instead of linking to an external resource we generate a similar table (possibly in ReST format) in makeunicodedata.py and include it with documentation.

New changeset fd7994909c2d by R David Murray in branch '3.4':
#18176: updated stdtypes UCD link, added reminder to makeunicodedata.
https://hg.python.org/cpython/rev/fd7994909c2d

New changeset 2551bdfff335 by R David Murray in branch 'default':
Merge: #18176: updated stdtypes UCD link, added reminder to makeunicodedata.
https://hg.python.org/cpython/rev/2551bdfff335

New changeset 303861ce9ead by R David Murray in branch '3.4':
#18176: fix another reference and add it to the makeunicodedata comment.
https://hg.python.org/cpython/rev/303861ce9ead

New changeset e9ec8d622a30 by R David Murray in branch 'default':
Merge: #18176: fix another reference and add it to the makeunicodedata comment.
https://hg.python.org/cpython/rev/e9ec8d622a30

I committed the stdtypes, lexical_analysis, and Tools changes, updating the version number appropriately in the doc fixes.

I'm closing this, and will open a new issue for the PropList.txt problem.

New changeset 73a6f121e51a by R David Murray in branch '3.4':
#18176: Change generic UCD PropList link to version specific link.
https://hg.python.org/cpython/rev/73a6f121e51a

New changeset b04b7af14910 by R David Murray in branch 'default':
Merge: #18176: Change generic UCD PropList link to version specific link.
https://hg.python.org/cpython/rev/b04b7af14910

I changed my mind and decided to "fix" the PropList reference to also be version specific, since that solves the immediate problem.  I opened a new issue for automating the changes, since there are three locations and four URLs, now.