homepage

Attached is a patch file that will update the readline functionality of
python in the following ways:
-- makes the tab-expand module be compatible with readline v6.x (fixes
the annoying extra-space bug)
-- removes '~$-/' from the completer chars list to make the next item work
-- adds filename completion to the completer, this is useful whenever a
filename/path is used
-- allows expansion to work properly on ClassType objects

This bug was reported in Arch (http://bugs.archlinux.org/task/15548) and
Gentoo (https://bugs.gentoo.org/show_bug.cgi?id=279234)

The patch should be broken into several, one for each bug fix or
enhancement.
Remarks and questions:
- is the readline v6.x fix (which I'm interested in) compatible with
previous readline versions?
- what does "removes '~$-/' from the completer chars list to make the
next item work" mean exactly? is it a bugfix or a new feature?
- I'm not sure filename completion is uncontroversial, it's the kind of
advanced features which we usually let third-party tools (e.g. IPython)
handle if they want to; it may also cause spurious IOs and error messages

Some clarification about the rest of the patch:
-- We tested the readline fix with version 5.2 and it seemed to work, we
did not do a thorough test with it, or with any other version.
-- When I supplied the patch I supplied the patch that we use when
building python, which also included some enhancements/bug fixes
(depending on how you look at it). By removing the '~$-/' characters
from the completer list it allows the user to perform file name
completion (with the provided file name completion code). The file name
completion code has been very rigorously tested. We have been using it
at our company for the past 10 years with >100 users and have had no
problems with it.
-- We put this here since it never really seemed to be an advanced
feature since readline completion will complete file names on the
command-line as well. This seemed like a relatively low-level fix that
makes the python tab-expansion facility fully usable instead of just
partly usable.
If you would like me to resubmit the patch as smaller components I can
do that as well.

Arch Linux devs have split the patch and applied only the extra-space
fix, which is what I'm attaching now. I've compiled Python 2.6.2 on
Gentoo with this patch and can report it works well (I tested with ipython).

I've committed the readline 6.0 fix to trunk, py3k and 3.1. I'll commit
it to 2.6 when the branch is unfrozen.

Now backported to py3k in r75747.

msg94560 should read "backported to the 2.6 branch". can we close the
report?

> Can we close the report?
Well there's something else in the original patch, although I don't care
about it.

How should we move forward with this issue?
J Evens: are you willing to split the patch in smaller ones that can be more easily managed/reviewed/applied?
Antoine: do you think it's worth the effort?
I can also try to split the patch, but what branch should I target: py3k?

> Antoine: do you think it's worth the effort?
As mentioned above, the readline 6 compatibility code was checked in.
The ClassType expansion is 2.x-only, so probably can't go in since it's a feature request.
What remains is the filename expansion. However, the problem is that it seems to rely on removing '~$-/' from the word break characters, which is IMO wrong (at least '-', '/' and '~' are all Python operators which should be considered word break characters).

I have no problem splitting the patch into multiple files. When I do so, do I place them here or open separate tickets for each component?
Or if you guys want to just close out the ticket since the actual bug was fixed, I am okay with that too. We will probably continue to use the patched version of tabexpand for our users since the filename expansion is used quite heavily. And since we will not be transitioning to py3k anytime in the next several years, we have no issue with what is (or is not) implemented there.

Looking at msg128306 and msg128319 I believe this can be closed.

Bug was fixed. Enhancements are out of date for 2.x and OP will not pursue for 3.x, and should be a separate issue anyway.