homepage

docs.python.org doesn't seem to be getting updated anymore. For example, this revision from Tuesday, Sept 11 is not reflected:
http://hg.python.org/cpython/rev/c8d60d0c736b 

http://docs.python.org/dev/py3k/reference/datamodel.html says "Last updated on Sep 11, 2012".

It has been 8 days since the last update.

The 2.7 docs seem not to be affected by this issue (they are current) -- just the docs for 3.2 and the default branch.

I believe Georg maintains cronjobs for updating the docs.

When the docs don't update, there's usually an error in running Sphinx.
In this case, the recently committed patch for #78982 (in the Unicode howto) prevents the LaTeX build (or more exact, the pdflatex run) from completing. Please revert that part of it.
(Aside: That is exactly the reason why I don't like these "make doctests run at all costs" patches.)

I think the issue was #15899, and the change 8a40bc71c072.

I'm working on it.

New changeset 0799fd1f8887 by Ezio Melotti in branch '3.2':
#15949, 15899: avoid using non-latin1 chars in the doc (they break `make all-pdf`).
http://hg.python.org/cpython/rev/0799fd1f8887
New changeset 832999a97e59 by Ezio Melotti in branch 'default':
#15949, 15899: merge with 3.2.
http://hg.python.org/cpython/rev/832999a97e59 

This should be fixed now.
It would be nice if Sphinx could send a notification mail in case of failure, so that the next time we will notice and fix the problem earlier.

I usually get the result of the cronjob via email if there's a failure; for a few weeks now this went to my spam folder, so I didn't immediately see something was wrong.

In the future, now that a few more people know, we could always look to see what doc changes were made since the last "publication" of the docs (or run the other `make` commands locally, or ideally, beforehand in cases that warrant it). The fact that 2.7 published and not the others should have been a tip off for me.
I wonder if `make patchcheck` could be enhanced to check for unsupported characters.
Lastly, is there a work-around for the inability to include � in the docs? That particular difference between u.encode('replace') and bytes.decode('replace') (? vs. �) seems like an important one to me not to conflate.

> I usually get the result of the cronjob via email if there's a failure;
Maybe it should go to python-committers or some other public ML, so that other devs can see and possibly fix the issue.
> I wonder if `make patchcheck` could be enhanced to check
> for unsupported characters.
That sounds like a good idea to me.
> Lastly, is there a work-around for the inability to include �
> in the docs?
'\ufffdabc' is acceptable, and it is what non-utf-8 terminals print.
> That particular difference between u.encode('replace') and 
> bytes.decode('replace') (? vs. �) seems like an important
> one to me not to conflate.
Indeed I was confusing the two. I'm not actually even sure that the Unicode standard mandates these specific replacement characters (IIRC there's even a way to configure them), and I was under the impression that '?' was sometimes used during the decoding, but after a few tests it seems I was wrong.

The distinction between ? vs. � for encode() and decode() is in the Python docs, but it's not prominent. It's mentioned in codecs's "Codec Base Classes" but not in the encode() and decode() docs themselves:
http://docs.python.org/dev/library/codecs.html#codec-base-classes 

> The distinction between ? vs. � for encode() and decode()
> is in the Python docs, but it's not prominent.
The point is that I'm not even sure we make any guarantees about the replacement characters that we use. I should check again what the Unicode standard says -- IIRC � was suggested, but it wasn't mandatory.

New changeset 9c666683e309 by Ezio Melotti in branch '3.2':
#15949, #15899: use \ufffd instead of ?.
http://hg.python.org/cpython/rev/9c666683e309
New changeset 1aebae2f68da by Ezio Melotti in branch 'default':
#15949, #15899: merge with 3.2.
http://hg.python.org/cpython/rev/1aebae2f68da