Readline and unwanted filename completion
mwh at python.net
Thu Feb 7 11:44:26 CET 2002
Simon Budig <simon.budig at unix-ag.org> writes:
> In article <u8za6pskh.fsf at python.net>, Michael Hudson wrote:
> > Simon Budig <simon at ping-pong.budig> writes:
> >> In article <uheowosxs.fsf at python.net>, Michael Hudson wrote:
> >> > Well, it can't go into 2.2. If you mean 2.2.1, that's a little
> >> > greyer; there might be people out there who rely on the current
> >> > behaviour.
> >> Hmm. Maybe it is possible to export this variable as an optional
> >> parameter to readline.set_completer with the default on the
> >> current behaviour?
> > But then that's a new feature...
> >> I think it is really annoying, that readline in the current
> >> python-module implementation insists on completing filenames when
> >> the completer returns no matches.
> > Sorry. But I don't think you can claim it's a pure bug, and so it's
> > not 2.2.1 material.
> Actually I think, that it is a bug, because it makes it impossible
> to write a completer function, that avoids the filename completion.
However, there may be people relying on current behaviour, and the
motto of x.y.z releases is "nothing breaks".
Also, to get it into 2.2.1 you have to convince the person putting
patches into the 22-maint tree, and that currently seems to be me, and
I'm not checking this one in.
> Imagine the rlcompleter: It is an convenient way to have completion
> on the Python commandline. But if you start typing a name that is
> not (yet) in the global dict and type <TAB> to verify this fact,
> readline decides to complete with a filename, which is absolutely
> meaningless in this context - AND YOU CANNOT SWITCH THIS OFF!
It can be useful too; I have actually done
>>> f = open("blabla
and then used tab-completion to finish it off.
> However, I am not familiar with the python guidelines/procedures for
> adding new features and certainly dont think that this is important
> enough to break these guidelines.
I should have mentioned this before:
> I am a little bit astonished, that it seems possible to add this to
> 2.1.x, but not to 2.2.x. Sounds weird to me.
Huh? Who said anything about 2.1.x? (If it was me, that was a typo
:). It'll go into *2.3*.
> For Gimp development we don't fix some misbehaviours in old
> versions, but are happy to fix them in new versions...
> Oh, well. Maybe I am missing something obvious here... :-)
Well, that 2.1.x != 2.3, perhaps...
incidentally, asking why things are "left out of the language" is
a good sign that the asker is fairly clueless.
-- Erik Naggum, comp.lang.lisp
More information about the Python-list