This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, docs@python, eric.araujo, georg.brandl
Date 2010-11-18.01:01:07
SpamBayes Score 0.0
Marked as misclassified No
Message-id <AANLkTikMxJm3LrEUtqHLEEq3WU8yLSLdKa=T4CBeThfV@mail.gmail.com>
In-reply-to <1290040083.28.0.103275818691.issue10446@psf.upfronthosting.co.za>
Content
On Wed, Nov 17, 2010 at 7:28 PM, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> Looks good.  Some remarks:
>
> 1) I assume you have checked that this code does not produce two newlines (one in the string,
> one from the print function or write method):

Yes, it should be clear from the output that I presented above.  I
think TextDoc.indent() takes care of the trailing '\n'.

That won't work for maintenance branches. (I am not even sure docs are
built for maintenance branches.)

> 3) People seem to go the the most recent version of the docs, not the release-specific version
> (I haven’t found the python-dev thread about that, maybe you remember it).
>  The version{add,chang}ed directives help adjust the doc for older versions.
>  So, are you sure it’s useful to make the links release-specific?

Certainly. If we are talking about the most authoritative source.  I
don't think versionadded/changed tags are reliable enough and you
don't want to send users to wrong docs when APIs change between
releases.   I am not so sure about micro-version, but there is no easy
way to construct the latest micro-version link without changes on
python.org.  If there was say latest/X.Y, I would use that.  Wait -
there is: docs.python.org/X.Y.  Would you prefer that?
History
Date User Action Args
2010-11-18 01:01:10belopolskysetrecipients: + belopolsky, georg.brandl, eric.araujo, docs@python
2010-11-18 01:01:07belopolskylinkissue10446 messages
2010-11-18 01:01:07belopolskycreate