On Sun, Aug 30, 2009 at 10:34:17AM +0000, Steven D'Aprano wrote: > > He's saying that instead of thinking the integer value of 3 itself being > > the object, he expected Python's object model would behave as though the > > entity m is the object, and that object exists to contain an integer > > value. > > > What is "the entity m"?
The entity m is an object. Objects, in computer science, are abstractions created by humans to make solving a large class of problems easier to think about. An object is a piece of data, upon which you can perform programmatic actions, which are grouped together with the values contained in that data. It's an abstraction which translates, in the physical sense, to a group of memory locations with a reference in a symbol table. > Ah wait, I think I get it... is m a memory location? No, it isn't. It is an abstraction in the programmer's mind that sits on top of some memory. For that matter, the memory location is itself an abstraction. It is not a memory location, but a particular series of circuits which either have current or don't. It is simply convenient for us to think of it as a memory location. > That would be how Pascal and C (and presumably other languages) > work, but not Python or Ruby or even VB (so I'm told) and similar > languages. Well, except that, in fact, they do work that way. They simply present a different abstraction to the programmer than C or other languages. They have to work that way, at the lowest level, because that is how the hardware works. > > Numbers are fundamentally different from objects. The number 3 is a > > symbol of the idea of the existence of three countable objects. It can > > not be changed > > Doesn't this contradict your claim that people expect to be able to > mutate numbers? That you should be able to do this? This is where you continually fail. There is no contradiction at all. What I'm saying is that in my view, numbers CAN'T mutate; they are not objects! They are values, which are a means of describing objects. Only the objects which hold the values can mutate. However in Python they don't, and can't, but they EASILY could with a different design. You, however, seem to be completely stuck on Python's behavior with regard to numeric objects, and fail to see past that. Python's model is only one abstraction, among multiple possibilities. > You can't have it both ways -- if people think of objects as > mutable, and think of numbers as not-objects and unchanging, then > why oh why would they find Python's numeric behaviour to be > unintuitive? Because in Python, they ARE objects, which they think should be mutable, but in Python when they try to change the *value* of the object, they don't get the same object with a different value; they get a completely different object. This is counter to their experience. If you don't like the Buick example, then use algebra. We've been down this road before, so I'm probably wasting my time... In algebra, you don't assign a name to a value, you assign a value to a variable. You can, in a different problem, assign a different value to that variable, but the variable didn't change; only its value did. In Python, it's the opposite. > What I think is that some people, such as you and Zaur, have *learned* > from C-like languages that numbers are mutable not-objects, and you've > learned it so well that you've forgotten that you ever needed to learn > it. No, this is precisely why I provided the real-world examples -- to illustrate to you that there was no need to learn it in computer science, because the concept applies in the real world quite intuitively in every-day situations. I think rather it is YOU who have learned the concept in Python, and since then fail to imagine any other possible interpretation of an object, and somehow have completely forgotten the examples you encountered before Python, from algebra and from the real world. > Human beings are excellent at reifying abstract things into (imaginary) > objects. I don't know what the word "reifying" means, but irrelevant. Such things are abstract, and in fact not objects. > No, the length of a car is an object which *is* a length, it doesn't > *have* a length. It is not an object. It is an abstract idea used as a description of an object. > None of this explains why you would expect to be able to mutate the > value three and turn it into four. Again, you fail. I *DO NOT* expect that. I expect to be able to mutate the object m, changing its value from 3 to 4. > I think you have confused yourself. No Steven, on this topic, it is only you who have been confused, perpetually. Although, it could be said that Python's idea of what an object is also is itself confused... Python (or at least the docs) actually refrains from formally defining an object. The docs only say that an object has an identity, a name, and a value. Well, OK... so 3 is an object. You can bind a name to it... except that's not exactly correct. You can bind many names to it, and every time you write something like: m = 3 You are binding another name to the same object. That's intuitive? So you say. But what is the value of 3? Is it 3? How can the value of an object be the object itself? If that were true, then the value of the object is an object, which has a value... you have an infinite recursion. It's a paradox. How could you get any more unintuitive than that?! In practice it's not a paradox, because the values inside numeric objects are *not* objects. They're numerical constants, as used by the hardware (excepting that they are just an abstraction on top of current, as noted before). Python's model breaks down at that point; it is not so with most other types of objects... their values remain objects. And *that* is inconsistent. The same is true of character data as for numeric data. And that, I believe, is why Java treats these as atomic data types, rather than as objects. Because they are, in fact. They are types of data that the hardware knows how to deal with, directly. Everything else is not. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgpxn3dTArJ69.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
