On 6/27/06, Brett Cannon <brett at python.org> wrote: > On 6/27/06, Jim Jewett <jimjjewett at gmail.com> wrote: > > (2) For the APIs returning an int, it wasn't clear what that int > > would be, other than NULL => interpreter is trusted. > Doesn't matter. I should probably change it to a say "a false value" > instead of NULL. But what if they succeed? Do they return -1, 1, the amount allocated, ... > > (3) Should PyXXX_Trusted have a variant that takes group/type/string, > > meaning "Am I allowed to do *this*?", rather than having to > > special-case the "You can do anything" case? > The PyXXX_Trusted() case is meant as a blanket trusted/untrusted test. If > you want more fine-grained, use the other checking functions (e.g., > PyXXX_ExtendedCheckValue(), etc.). You gave an example of a library that was generally useful even in restricted mode, but had one convenience function that shouldn't always be permitted. I imagine a function that is dangerous only because it takes a filename rather than an open stream; I want to wrap it in some sort of guard, but I would rather make a single "Can I do this?" query. Under the current API, I would need separate logic for "The interpreter is completely trusted" and "The interpreter is not trusted, but can do _this_". In practice, I'm betting that many extension modules will skip at least one of these steps. -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