Terry J. Reedy <tjre...@udel.edu> added the comment:
(Note: the word is 'separate', 2 e's and 2 a's, not 'seperate')
(Note: We already know that using unbound unquoted names does not work. Please
do not waste our time telling us the obvious.)
(Note: I am removing IDLE because this does not seem to be an IDLE issue but a
help() issue. I marked 'Library' because 'help' is installed by the site
module.)
Help is not built in to python.exe. It is added to builtins when the site
module is imported. That import can be suppressed with the '-S' startup option.
It is strictly intended for interactive use.
I do not see this as much of a security issue. Crashing apps and especially
servers should not be an issue because neither should be using help. Anyway, I
should think that a hacker that can install a broken C extension could do much
worse things.
Help has three modes.
1) the direct response mode of help(ob)
2) the direct response mode of help(somestring), where help looks to see if it
recognizes somestring before returning help for str.
help('modules') works fine.
3) the mini-interpreter mode of help(). People can run the mini-interpreter in
a separate interactive instance of the interpreter if they wish. I do not think
this needs to be done automatically.
I am inclined to close this issue as I do not see any action needed by Cpython
developers. Contrary to your assertion, running corrupt C-coded extensions
*does* crash the process, and I do not think there is much we can do about it,
as C lacks try:...except:. Certainly, there is no promise to guard against
such. In my view, removing a corrupt package is an answer, not a workaround!
----------
components: +Library (Lib) -IDLE
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
