First, it's in __builtin__. That reference can just be left out of the dict at the PyInterpreterState stuct's dict for built-ins. But we all know it isn't that simple.
Second, there is __subclasses__(). That method could just not be allowed to be in the 'type' class at the Python level (hiding it, crippling it, whatever), but would that break much code? I don't know, but I doubt it.
Third, for any wrappers returned by open(), it cannot be a subclass because chaining __class__ attribute, mro() (or any of the other methods provided on 'object' or 'type'), or type() will get you to the original 'file' type. The actual 'file' reference will need to be stored at the C struct level for the wrapper and not accessed except by the wrapper directly which would be implemented in C.
Can anyone think of any other way to gain access to 'file' without importing a module? At that point one would need to be *very* careful about what an extension module exported to the world, but I can live with that (as that is already part of the plan).
Please seriously try to think of ways to get to 'file' everybody. If we really cannot come up with anything beyond these three ways, then I am totally willing to go with a much more complete capabilities system for security in Python and really minimize any crippling. I just need to be convinced that we won't be plugging holes in how to hide 'file' rather than plugging holes from crippling 'file' (which, at this point, I am not convinced of).
And if Armin and/or Samuele sign off that what we find is most likely (with "most likely" equalling 99% chance) all there is, then bonus points and I will *really* be convinced. =)
_______________________________________________ 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
