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.