Fredrik Lundh wrote: > Bryan Olson wrote: > > >>I think the following is correct: an object's identity is not part >>of its value, while its type is. > > > you're wrong. an object's identity, type, and value are three different > and distinct things.
If I do: >>> mylist = [17, 24] are mylist and 17 different and distinct things? Suppose I define a member attribute/property called '_class_', that will get the save value as '__class__'. Now is that type part of the value of an object of my class? [...] >>Python queries objects for their types; it's now a user-visible feature: >> >> >>> 'hello'.__class__ >> <type 'str'> > > > To get an object's type, use type(x). This has always been a user- > visible feature (along with id(x)). Commanding that I get it some other way isn't going to change that that type is now user-accessible as an attribute of the object. The new-style classes tutorial calls it a "Python-provided attribute". http://www.cafepy.com/article/python_attributes_and_methods/python_attributes_and_methods.html Maybe one could to describe a consistent semantics that distinguishes Python-provided attributes as unlike other attributes, in that we define them not to be part of the object's value. I don't that that would be wise. [...] > Nobody's saying that the identity and the type is not a "property" of the > object (for a suitable definition of property, that doesn't include Python > properties). Sure, and whether the Interpreter queries the object for the type is an implementation detail, and maybe a point-of-view issue. But now the type is available as a Python-provided attribute. > What the documentation and I are saying is that it's not a > part of the object's *value*. Where does the doc say that? > An object's identity, type, and value are three different and distinct things > (or "properties", if you prefer). End of story. The story continued. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list