Sun, 30 Mar 2003 14:53:59 -0600 (CST)
On Sun, 30 Mar 2003, Guido van Rossum wrote:
> > Having access to a particular instance should certainly not allow
> > one to ask it for its class, and then instantiate the class with
> > arbitrary constructor arguments.
> Assuming the Python code in the class itself is not empowered in any
> special way, I don't see why not. So that suggests that you assume
> classes can be empowered. I can see this for classes implemented in
> C; but how can classes implemented in pure Python be empowered?
In many classes, __init__ exercises authority. An obvious C type with
the same problem is the "file" type (being able to ask a file object
for its type gets you the ability to open any file on the filesystem).
But many Python classes are in the same position -- they acquire
authority upon initialization.
To pick one at random, consider zipfile.ZipFile. At first glance it
appears that once you create a ZipFile object with mode "r" you can
hand it off to provide read-only access to a zip archive. (Even if
a security audit of the code reveals holes, my point is that the API
isn't far from accommodating such a design intent.)
It's useful to be able to separate the authority to read one
particular instance of ZipFile from the authority to instantiate
new ZipFiles, which currently allows you to open any zip file on
the filesystem for reading or writing.