On 6/27/06, Brett Cannon <brett at python.org> wrote: > On 6/27/06, Jim Jewett <jimjjewett at gmail.com> wrote: > > > On 6/27/06, Brett Cannon <brett at python.org> wrote: > Shouldn't be as long as you put the call right after variable declarations > and you don't do an PyObject creation at variable declaration time. When PEPping this, please add that restriction to the Extension Module Crippling section. > > I just want a single call that does my erroring out, instead of two > > separate calls depending on whether the interpreter is trusted. > Oh, you won't! You have the set call before you even start using the > interpreter to define your restrictions; that has a return value to flag > that you are trying to set restrictions on a trusted interpreter, and thus > are trying to do somethign that just won't work. Then you have the check > functions that run in *any* interpreter. This is what I was missing -- the bit about who uses which part of the API. Is the following correct: Py_XXXCheck* and Py_XXXExtendedCheck* are called by C extension modules. They error out of the current function if the action would not be allowed. (In the special case of of a fully trusted function, the happen to compile themselves out.) There may be some Py_XXXInfo functions added to find out what the limits are, particularly for python code. Py_XXXTrusted() should really be renamed Py_XXXCheckTrusted(). Crippled extension modules should really use Py_XXXCheck*, but PyXXXCheckTrusted is a quick way to get all-or-nothing. No other PyXXX functions should ever be (directly) called by any loadable module, not even by C extension modules; they are called only by an embedding program. -jJ
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4