You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/nascheme'closed_at=<Date2008-05-11.21:04:17.220>created_at=<Date2008-03-07.10:49:56.552>labels= ['easy', 'type-bug', 'library']
title='rlcompleter raises Exception on bad input'updated_at=<Date2008-05-11.21:04:17.121>user='https://bugs.python.org/donlorenzo'
in line 130 rlcompleter calls eval on the first part (before the last
dot) of the input text.
if that part is not valid it will raise an exception which is likely to
crash a calling application.
the patch puts the eval call in a try-except block and catches Name- and
AttributeErrors and returns an empty list (the behavior when no matches
are found).
Is a straightforward patch, but I'd like NAS to comment on the change in
behavior. Probably would also need a documentation change, are you up
for doing that Lorenz?
I have no idea what or who NAS is but comments are always welcome :)
concerning the documentation:
I´ve never done it before but there is a first time for everything,
right? I´m currently on vacation so I won´t look into it for at least
another 2 weeks.
On Thu, Mar 20, 2008 at 08:49:32PM +0000, Sean Reifschneider wrote:
Is a straightforward patch, but I'd like NAS to comment on the change in
behavior. Probably would also need a documentation change, are you up
for doing that Lorenz?
I doubt that people are relying on complete() to raise NameError or
Attribute error. I think it would be okay just to trap them and not
change the docs. A note in NEWS should be good enough.
Neil
donlorenzo commented on Mar 26, 2008
donlorenzomannequin
MannequinAuthor
More actions
I was thinking that the code in question could maybe also raise other
exceptions. too bad I´m on vacation and can´t try this out myself.
I believe the regular expression also matches something like
which I guess would result in a SyntaxError.
would be nice if someone could verify that.
If I´m right I see two possibilities. either change the regular
expression to match only valid python identifieres or also catch
SyntaxErrors.
could there be any other exception? ("In the face of ambiguity, refuse
the temptation to guess.")
donlorenzo commented on Apr 4, 2008
donlorenzomannequin
MannequinAuthor
More actions
I confirmed that the rlcompleter can raise a SyntaxError on bad input.
Upon further investigation I found that a ReferenceError could also be
raised. I didn't check on other Exceptions.
I attached a new version of the patch where I catch all Errors derived
from Exceptions (not SystemError and KeyboardInterrupt).
while this seems rather drastic I really feel that this step should in
no case raise an Exception. I can't possibly think of a situation where
someone would want that.
Concerning the docs:
"...it will try to evaluate anything without obvious side-effects..."
I would consider raising an exception as a major side-effect so this
patch rather brings the code into accordance with the docs than it
contradicts them.
donlorenzo commented on Apr 18, 2008
donlorenzomannequin
MannequinAuthor
More actions
I attached a patch for the docs.
It now states that the rlcompleter.Completer will catch and silence all
exceptions raised by evaluating the expression passed to complete()
donlorenzo commented on Apr 18, 2008
donlorenzomannequin
MannequinAuthor
More actions
In the last patch I used the wrong ticks. I hope it's fine like this.
Activity
donlorenzo commentedon Mar 7, 2008
in line 130 rlcompleter calls eval on the first part (before the last
dot) of the input text.
if that part is not valid it will raise an exception which is likely to
crash a calling application.
example 1:
==========
example 2:
==========
the patch puts the eval call in a try-except block and catches Name- and
AttributeErrors and returns an empty list (the behavior when no matches
are found).
jafo commentedon Mar 20, 2008
Is a straightforward patch, but I'd like NAS to comment on the change in
behavior. Probably would also need a documentation change, are you up
for doing that Lorenz?
donlorenzo commentedon Mar 24, 2008
I have no idea what or who NAS is but comments are always welcome :)
concerning the documentation:
I´ve never done it before but there is a first time for everything,
right? I´m currently on vacation so I won´t look into it for at least
another 2 weeks.
nascheme commentedon Mar 25, 2008
On Thu, Mar 20, 2008 at 08:49:32PM +0000, Sean Reifschneider wrote:
I doubt that people are relying on complete() to raise NameError or
Attribute error. I think it would be okay just to trap them and not
change the docs. A note in NEWS should be good enough.
Neil
donlorenzo commentedon Mar 26, 2008
I was thinking that the code in question could maybe also raise other
exceptions. too bad I´m on vacation and can´t try this out myself.
I believe the regular expression also matches something like
which I guess would result in a SyntaxError.
would be nice if someone could verify that.
If I´m right I see two possibilities. either change the regular
expression to match only valid python identifieres or also catch
SyntaxErrors.
could there be any other exception? ("In the face of ambiguity, refuse
the temptation to guess.")
donlorenzo commentedon Apr 4, 2008
I confirmed that the rlcompleter can raise a SyntaxError on bad input.
Upon further investigation I found that a ReferenceError could also be
raised. I didn't check on other Exceptions.
I attached a new version of the patch where I catch all Errors derived
from Exceptions (not SystemError and KeyboardInterrupt).
while this seems rather drastic I really feel that this step should in
no case raise an Exception. I can't possibly think of a situation where
someone would want that.
Concerning the docs:
"...it will try to evaluate anything without obvious side-effects..."
I would consider raising an exception as a major side-effect so this
patch rather brings the code into accordance with the docs than it
contradicts them.
donlorenzo commentedon Apr 18, 2008
I attached a patch for the docs.
It now states that the rlcompleter.Completer will catch and silence all
exceptions raised by evaluating the expression passed to complete()
donlorenzo commentedon Apr 18, 2008
In the last patch I used the wrong ticks. I hope it's fine like this.
birkenfeld commentedon May 11, 2008
Committed code and doc patches as r63094. Thanks!