On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
