The Doc/Python262.chm file needs to be named Doc/Python26.chm so that
IDLE can find it.  The current release cannot find the chm file at all
so it falls back to the on-line docs at http://www.python.org/doc/current .

This also applies to Python31a2.chm --> Python31.chm

It's actually vice versa - IDLE should open the file under its correct name.

What changed here?  ISTM that IDLE was always looking for the same name
and that the new part is that the build procedure has been been changed
(the step where the "make htmlhelp" output file is moved to ./Doc and
renamed).

It looks like IDLE has been the same since 2004:
 
http://svn.python.org/view/python/trunk/Lib/idlelib/EditorWindow.py?view=diff&r1=36600&r2=36601

The "correct" filename is what has changed.  

The release process needs to have a step that validates that the CHM
file works from IDLE.

FWIW, I think the version naming convention is unnecessary and makes the
IDLE linkage too fragile.  It would be better to just always call the
file Python.chm.  By way of comparison, the regular html docs do not get
custom names -- they are just index.html in a doc directory.

Just checked Python2.5.4 and its CHM file is Python25.chm.  So
everything is fine with that release.

> What changed here?

We switched to sphinx, and the makefiles put the full version into the
output files.

> ISTM that IDLE was always looking for the same name
> and that the new part is that the build procedure has been been changed
> (the step where the "make htmlhelp" output file is moved to ./Doc and
> renamed).

No, the "make htmlhelp" output is already called python262.chm. So no
renaming occurs.

> The release process needs to have a step that validates that the CHM
> file works from IDLE.

I personally can't perform such testing steps, perhaps unless somebody
maintains a list of such steps for me.

Instead, I think such problems must be detected during beta testing.
The fact that it hasn't been detected so far, even though it existed
since 2.6.0, indicates that the problem can't be that serious.

> FWIW, I think the version naming convention is unnecessary and makes the
> IDLE linkage too fragile.  It would be better to just always call the
> file Python.chm.  By way of comparison, the regular html docs do not get
> custom names

That's not true: they are called e.g.

python-2.6.2-docs-html.tar.bz2
(see http://docs.python.org/download.html)

I believe that the rationale for calling the CHM file that way is the
same as for putting a version number into any other output.

FWIW, the renaming had caused some troubles in the past, but most of
it is over. Renaming it back will cause more troubles for sure.

> Just checked Python2.5.4 and its CHM file is Python25.chm.  So
> everything is fine with that release.

True. The renaming happened with the switch to sphinx.

I think idle should be updated to look for the correct file name.

Maybe the functions in Doc/tools/sphinxext/patchlevel.py should be moved
to somewhere else then ? IDLE could use them.

> Maybe the functions in Doc/tools/sphinxext/patchlevel.py should be moved
> to somewhere else then ? IDLE could use them.

No. IDLE shouldn't parse the version out of the header file, but instead
use sys.version_info to compute the file name, so it's really just
get_sys_version_info, and you only need half of its return value.
Copying it is fine, IMO.

Fine, Martin. Patch attached for idle only.

Fragile solution, but it works.  IMO, it's a better design to just have
the file named Python26.chm like it always used to be done.   Now, we've
duplicated someones arbitrary logic (ignoring sys.version_info.serial
and special casing sys.version_info.release_level=="final") but the
duplication isn't exact because the original puts dots better the major,
minor, and micro versions.  This is asking for another bug someday when
the logic gets changed in one place but not the other.

> Fragile solution, but it works.  IMO, it's a better design to just have
> the file named Python26.chm like it always used to be done.

That was also fragile, as this bug report demonstrates. It broke when
sphinx decided to put more version information into the file names.

So when the file naming algorithm changes in one place and not the
others, it *will* break, no matter what the old algorithm was. The
lesson to be learned is that you just should be *very* careful to ever
change file names. Applying that lesson to the status quo means that
IDLE has to change, not the file name of the CHM file.

r71812 in trunk. Will port to 3-head 30-maint 26-maint.
Thanks for the patch!

"Instead, I think such problems must be detected during beta testing.
The fact that it hasn't been detected so far, even though it existed
since 2.6.0, indicates that the problem can't be that serious."

I believe I tried F1 Help once, got the online docs, found that
annoying, but did not report because I did not know it was a bug.  I
usually keep .chm open anyway when writing code.  Being able to open
from IDLE would be nicer than via Start / All Programs / Python 3 / docs.

With 3.0.1, I just tried again, but got
"Not Found

The requested URL /dev/3.0/ was not found on this server.
Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_ssl/2.2.9 OpenSSL/0.9.8g
mod_wsgi/2.3 Python/2.5.2 Server at docs.python.org Port 80"

so going online is really broken.

Terry, I believe your issue (online docs not found in 3.0) is different
from this issue, so please open a new issue.

I'm leaving this open until the patches have been forward-ported.

My point, relative to this issue, was to explain why I had not commented
before, but also to report that forward porting is needed, and not just
a convenience.  I just reported the breakage to webmaster@python.org.

The issue that Terry Reedy raised is due to 68801 being forward
ported to py3k but not backported to 2.6-maint or 3.0-maint.
Access in 2.6.2 happens to work because there's a redirect on
the website which points to the correct doc release.  But 3.0.1
is broken.  I will fix both of those when I port.

Perhaps the reason the chm issue hasn't been more widely reported is that
the chm docs are available from the Python selection in the Start
menu on both releases.

This isn't a problem for the Python webmaster.  We don't want
them starting to change the links underneath us!

I used 'pending' in the Debian sense of: "I'm working it, 
expect an upload soon."  Unless I'm mistaken, there's no bot
closing 'pending' like  there was on SF.  How do the devs
generally use the 'pending' tag?

> I used 'pending' in the Debian sense of: "I'm working it, 
> expect an upload soon."  Unless I'm mistaken, there's no bot
> closing 'pending' like  there was on SF. 

Actually, the Pending status is exactly the one as there was
on SF. The bot closing it just hasn't been installed yet.

OK, thanks, Martin.  I'll use 'pending' that way (close after a 
while if the bot hears nothing further).

Changing component to "IDLE'.
release26-maint: r71908, r71909

Kurt, I'm not sure if you misunderstood Martin but there is no such
"closing bot" here (only if you consider people as bots :)

Anyway, are you porting these to py3k and release30-maint or can someone
else do it ?

> Kurt, I'm not sure if you misunderstood Martin but there is no such
> "closing bot" here (only if you consider people as bots :)

There is no such bot *yet*, but may be in a few days.

I understood Martin completely.  The bot is coming RSN.  My use
of 'pending' was intended to answer the exact question you just
asked.  Maybe I should use Stage: 'commit review'.

Forwardport to py3k: r71952
Backport to 30-maint: r71953