Greg Ewing wrote:
> Another thing I perhaps should point out is that
> I'm proposing the separation of open() and file()
> for *all* code, not just restricted code. So it's
> not a matter of "crippling" file() specially for
> restricted code.
What would the signature of the file constructor be in that case? Would it
accept a single CObject instance, with open() bypassing the normal
constructor, and handing the file pointer directly to the file object instance?
It seems like a reasonable approach for making 'dangerous' objects like file
and socket much easier to secure - have a separate factory function to create
*new* instances at the C level, so that you can hand the objects over without
worrying about providing access to the constructor (because the constructor
*accepts* the OS-level object as an argument, rather than creating it anew).
Alternatively, using a "no-Python-level-introspection" metaclass might be
another way to achieve the same effect in a more universal fashion.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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