On Nov 15, 4:12 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >> On Nov 14, 8:56 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: ...snip... >>>> * Does an object's behavior (methods) affect >>>> its value? >>> My first answer is No. Instance methods are attributes of a class and, >>> in most cases, the value of a class.
So if method .foo() is an instance attribute it is part of the object's value, but if it is part of the object's class, it is part of the object's behavior? Even though calling obj.foo() causes exactly same results? I can see that a case can be made for defining things that way, but it doesn't seem desirable. >> The value of a class is it's attributes? >> Are you saying that attributes of an object are >> part of its value? > > Either: objects have 4 aspects -- id, class, attributes, and value > Or: attributes are included with value, so that obs have 3 aspects -- > id, class, and value. > [Or: (Aprano) id, class, and attributes are included with value.] Or: object attributes are considered together with class attributes to define an object's behavior leading to: obs have 3 aspects -- id, behavior, and value. (The definition of "type" might be stretched a little to make it synonymous with behavior.) > I an not sure yet which viewpoint/formulation is the more useful. I > answered from the 3-aspect viewpoint. It is more traditional, but > probably predates 'objects with attributes' as opposed to 'strucures > with fields'. But I suspect that the values of the fields would be > considered the value of the structure. In any case, I have also > considered the 4-aspect view also. > >> That would mean that 'a' >> and b' below have different values? >> >> class My_int(int): >> def __init__(self): self.foo = None >> a = int(3) >> b = My_int(3) > > Yes, and indeed, a.foo raises an exception and b.foo does not. But raising an exception is a aspect of behavior, not of value. > If attributes are included with value, then value must be subdivided > into attributes and private value. For numbers, the private value is > the numerical value; it cannot be accessed separate from the number > object itself. Strings have a private value which can be exposed a > character or slice at a time. Numbers and strings are the two classes > with literals. It seems to me that what I think of as "value" is indeed a sort of private attribute (that's how I am trying out thinking of it.) But it is its privateness, its totally different way of getting created, used, and changed, that is the very thing that makes it unique and worthy of getting it's own name. >> I propose that attributes are not part of a class' >> (or any other object's) value and that a class object >> has no value. > > That is the first choice of the either/or choice above. It is okay as > long as it is understood that 'value' is being used in a restrictive sense. Which seems to me to most closely match the intuitive sense of value. To me it is intuitive that int(3) and subclass_of_int(3) have the same value, 3. To learn that their values are different because one has an attribute the other didn't, or because the values in a common (in name) attribute were different, would be very surprising to me. > Here is one reason I have not adopted it yet (and I need to make a > choice for the algorithm book I am writing). Consider a(b). This means > 'call a with argument b'. I would rather say 'the value of a is what it > does with b (for all possible b), which is to say, the mapping it > implements', than to explain calling in terms of an > implementation-dependent, essentially private, attribute structure. I can see viewing functions in general as a mapping of arguments values to results in the context of describing algorithms. I am not sure it is the best way to view them in the context of how objects are manipulated in the Python runtime environment. > So I am thinking I may go with > class: determines universe of possible values of instances and (with > superclasses) functions such instances can work with. If attributes are part of an object's value, that universe is effectively infinite, isn't it? For the vast majority of objects (those created in Python from a class not designed to impose bondage and discipline by using slots for example) I can add any attributes I wish with any values I wish to an object. So class doesn't really determine much under that definition, does it? > 'Functions' > includes all types of syntactic expressions. Doesn't that use of the word "function" conflict with the already established use of "function" in Python. I.e., I think of functions as just another object, albeit one with a code attribute that the Python VM knows how to call. I think of evaluation of expressions as a series of method (or other callable) executions, each returning an object that is used in the next step of the series. > value: determine specific result when used as argument in functions You are prepared to redefine everything about objects. I was trying to restrict my redefinition to only value. But I see your point that the existing definition of object does not handle instance attributes very well either. In comparing your definitions with mine, I think I see a difference in view point. It seems to me you give greater attention to class, whereas my mental model of Python focuses more on individual objects. I think I was led to that view by Python's very dynamic behavior. One can dynamically coerse an A instance into behaving nearly indistinguishably from a B instance. So what A was before seems some- what academic. I tend to think of an object's class as a template for creating new instances and a convenient place to stash common attributes to avoid duplicating them in each instance. (Is this too simplistic?) So I think of behavior (as defined by attributes) to be more closely related to the instance than the class. In my model, there is not a big problem not making a strong distinction between class attributes and an instance's attributes -- I think of the union of the object's attributes, its class' attributes (and superclass attributes recursively) as all being virtually part of the instance. Python itself encourages this view I think. A while ago I tried to write an object examiner and found it hard to figure out, in the results for inspect.getmembers(obj), which belonged to obj, which obj's class, obj's class' superclass, etc. Same with dir()'s results. -- http://mail.python.org/mailman/listinfo/python-list