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 | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org _______________________________________________ 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