Is 'everything' a refrence or isn't it?

[Fredrik Lundh]

So, was it an editing error when you said that Python does not
query the object to determine its type? The type is there in the
object, and and in Python, variables and references are not typed.

do you want to understand this, or do you just want to argue ?

(hint: what might the word "query" mean in this context? can you think
of a meaning that's compatible with what I wrote? would concepts like
"object", "value", "type", and "identity" be radically different on a python
implementation that used e.g. "true" garbage collection and tagged pointers
instead of CPython's approach? if so, why?)

</F>

 

[Scott David Daniels]

Let's try not to be too deep here, okay? Before asking "what is the value
of foo?", we have to agree on what we mean by "value". It is easy to tie
yourself into knots here.

An important help to some people's understanding of objects is realizing
how they are used. Sometimes an object is used to mediate between the
real world and a program. For example, you could design an object which
controlled a printer, and inserted line breaks a page-ejects as needed.

The "value" of the printer object is not safely replicable -- you cannot
copy the state of the printer object, attempt to print something, and
if there is a failure (like "out-of-ink") restore the former state of
the printer and try another method. The ink has run out. Nothing in
one exclusively in software can get you back to the state where you
had more ink. So for such things, the "state" of an object is more
than simply the rich detail of a data structure.

Much more common are objects which communicate with other systems
(either over network connections or locally on the machine). The
point where a "value" cannot be restored greys as you examine
these cases.

--Scott David Daniels
(e-mail address removed)

 

[Antoon Pardon]

All objects ARE values. Some values themselves are complex objects
which in turn contain other values, e.g. if I execute:

I don't agree with this wording. If a mutable object mutates it
is still the same object but is's value has changed. So I would
agree with: objects have values.

L = [None, 1, "hello"]

I have created a name 'L' which is bound to ("has the value of") a list
with three items. The first item has the value of ("is the object") None,
the second has the value of ("is the object") 1, and the third is the
string "hello".

But if you execute L.append(False) then L is still the same object
but it's value is different.

 

[Aahz]

An important help to some people's understanding of objects is
realizing how they are used. Sometimes an object is used to mediate
between the real world and a program. For example, you could design
an object which controlled a printer, and inserted line breaks a
page-ejects as needed.

The "value" of the printer object is not safely replicable -- you
cannot copy the state of the printer object, attempt to print
something, and if there is a failure (like "out-of-ink") restore the
former state of the printer and try another method. The ink has run
out. Nothing in one exclusively in software can get you back to the
state where you had more ink. So for such things, the "state" of an
object is more than simply the rich detail of a data structure.

Yup. I sometimes say in such cases that the object is a proxy for some
other object (sometimes real-world, sometimes not -- as in the case of a
GUI object).

 

[Bryan Olson]

Bryan Olson wrote:




do you want to understand this, or do you just want to argue ?

Both!

I think the following is correct: an object's identity is not part
of its value, while its type is.

(hint: what might the word "query" mean in this context? can you think
of a meaning that's compatible with what I wrote?

I don't think usage of "query" is the issue. Python queries
objects for their types; it's now a user-visible feature:

> would concepts like
"object", "value", "type", and "identity" be radically different on a python
implementation that used e.g. "true" garbage collection and tagged pointers
instead of CPython's approach? if so, why?)

Python would still be duck-typed and the type would still be a
property of the object. Implementation-wise and behavior-wise,
Python queries objects for their types.

 

[Mike Meyer]

|> 3. If two objects are equal with "==", does that
|> mean their values are the same?
Yes.
| >>> 3.0 == 3
| True
Evidently the value of 3.0 is the same as the value of 3.

And they do. They are two different representations of the same
value. More in another thread.

<mike

 

[Mike Meyer]

The Python manual's claim there is solidly grounded. The logic
of 'types' is reasonably well-defined in the discipline. Each
instance of a type takes exactly one element from the type's
set of values (at least at a particular time).
References?

Whether the '==' operation conforms to your idea of what equality
means is unclear.

Care to say what it does mean, then?

Maybe I was wrong, and the object's identity
is part of its abstract state.

Is abstract state always part of the value?

We know that's not true.

You claim it's not true, but didn't provide anything to back up those
claims, or even alternatives to explain the apparent discrepancy in
behavior.

<mike

 

[Mike Meyer]

|> 2. What is the value of object()?
[ I assume you mean, the object returned by object(). ]
It doesn't really have a value. I can't think of any kind of
computation that could use this object directly.

Here is one:
obj_inst = object()
def computation(data):
global obj_inst
if data is obj_inst:
print FirstOneThousandPrimes()
else:
print TextOfWarAndPeace()
It isn't a particularly useful computation, but it is a computation.

And it doesn't use the value of the object instance, it uses it's
identity. Any type that doesn't have hacks to share instances with the
same value could be used in this way.

Let's try not to be too deep here, okay? Before asking "what is the value
of foo?", we have to agree on what we mean by "value". It is easy to tie
yourself into knots here.

I think you want to settle what we mean by "type" first. Or maybe in
parallel.

<mike

 

[Paul Rubin]

Care to say what it does mean, then?

class boffo(int):
def __eq__(x,y): return True

a,b = boffo(2), boffo(3)
print a+b, a==b, (a+2)==(b+2)

I'd say a==b doesn't necessarily mean a and b have the same value.
At minimum, if a and b have the same value, I'd expect a+2 to be
the same as b+2. So in this case, a==b but they have differing values.

 

[Steven D'Aprano]

I don't agree with this wording. If a mutable object mutates it
is still the same object but is's value has changed.

Yes. And this is a problem why? Some values are fixed, and some values are
changeable.

So I would agree with: objects have values.

I don't believe this is a useful distinction to make.

L = [None, 1, "hello"]

I have created a name 'L' which is bound to ("has the value of") a list
with three items. The first item has the value of ("is the object") None,
the second has the value of ("is the object") 1, and the third is the
string "hello".

But if you execute L.append(False) then L is still the same object
but it's value is different.

Yes. Values can change. So what?

 

[Steven D'Aprano]

|> 2. What is the value of object()?
[ I assume you mean, the object returned by object(). ]
It doesn't really have a value. I can't think of any kind of
computation that could use this object directly.

Here is one:
obj_inst = object()
def computation(data):
global obj_inst
if data is obj_inst:
print FirstOneThousandPrimes()
else:
print TextOfWarAndPeace()
It isn't a particularly useful computation, but it is a computation.

And it doesn't use the value of the object instance, it uses it's
identity. Any type that doesn't have hacks to share instances with the
same value could be used in this way.

Since it is my position that the identity of an instance of object() _is_
its value, your argument doesn't concern me whatsoever.

object instances are like electrons (note for pedants: in classical
physics, not QED): they are all exactly the same, distinguishable only by
their position in time and space (or memory location).

 

[Mike Meyer]

I'd say a==b doesn't necessarily mean a and b have the same value.

Care to say what it does mean (as opposed to what it doesn't mean), then?

<mike

 

[Mike Meyer]

On Thu, 12 Jan 2006 16:11:53 -0800, rurpy wrote:
It would help if you or someone would answer these
five questions (with something more than "yes" or "no"
1. Do all objects have values?
All objects ARE values. Some values themselves are complex objects
which in turn contain other values, e.g. if I execute:

I don't agree with this wording. If a mutable object mutates it
is still the same object but is's value has changed. [...]
So I would agree with: objects have values.

I don't believe this is a useful distinction to make.

If two objects ARE the same value, then they should be the same
object. If two objects HAVE the same value, then they may or may not
be the same object. In particular, if the value is mutable, and you
change one object that is some value you change the value, but the any
other objects that are that value are still the old value of the value
(um, I hope you know what I mena).

This problem - and the vocabulary problem I just illustrated - both go
away if objects have values instead of are values.

<mike

 

[Mike Meyer]

object instances are like electrons (note for pedants: in classical
physics, not QED): they are all exactly the same, distinguishable only by
their position in time and space (or memory location).

Except all electrons aren't exactly the same - because they have a
value over and above their location. If you want to be pedantic, you
can claim that electrons with a positive charge aren't really
electrons.

In either case, what's the object's equivalent for "electric charge"?

<mike

 

[Donn Cave]

Quoth Mike Meyer <[email protected]>:
|>> > Whether the '==' operation conforms to your idea of what equality
|>> > means is unclear.
|>> Care to say what it does mean, then?
|> I'd say a==b doesn't necessarily mean a and b have the same value.
|
| Care to say what it does mean (as opposed to what it doesn't mean), then?

I'm happy to say "==" means "the same" when applied to values, but one
could reasonably object that "the same" ought to account for all properties
of a value, and not just equality. The issue doesn't seem to come up when
writing programs, though, in my experience.

Donn Cave, (e-mail address removed)

 

[Steven D'Aprano]

Care to say what it does mean (as opposed to what it doesn't mean), then?

Since you can overload __eq__, it means anything the programmer wants it
to mean. And if there is a bug, something he doesn't mean.

But ignoring pathological cases, a==b means that a and b are equal,
whatever equal means in the context. Equal might mean that a and b:

- are the same object;
- are different objects with equal values;
- are different objects with equivalent values;
- have the same value when converted to a common type (which may or may
not be the type of either a or b);
- are "close enough" to treat as if they were the same;
- represent the same abstract quantity or quality;
- have the same printable representation;
- or something else!

But note that even if one or more of these are true, it doesn't
necessarily mean that a==b will return true. "two" and "deux" both
represent the same abstract quantity, but no programming language I know
of will recognise them as equal.

And then there is this potent source of bugs:
True

Since when is a distance comparable to a weight, let alone equal?

 

[Mike Meyer]

True
Since when is a distance comparable to a weight, let alone equal?

The latest (and most impressive to date) to fix this is frink:
<URL: http://futureboy.homeip.net/frinkdocs/ > The examples section is
particularly amusing.

<mike

 

[Bryan Olson]

References?

Are not hard to find. In Niklaus Wirth's /Algorithms + Data
Structures = Programs", the first section after "introduction"
"The concept of data type". Wikipedia has reasonable articles
on datatype and abstract datatype. That an instance takes a
value is too obvious to state, but clearly implied by discussion
of an object's value. If you're familiar with other programming
languages, you can to those. There are no values of C's 'void'
type, and consequently there are never any objects of type void.

Care to say what it does mean, then?

I think that's now been answered a few times. In this case,
it means comparison of object identity.

Is abstract state always part of the value?

The abstract state, sometimes called the "logical state", is
the value the object represents.

You claim it's not true, but didn't provide anything to back up those
claims, or even alternatives to explain the apparent discrepancy in
behavior.

I didn't see a discrepancy in behavior and the manual is the
definition of the language. The concept of a valueless object
is inconsistent with a great deal material.

 

[Steven D'Aprano]

Except all electrons aren't exactly the same - because they have a
value over and above their location. If you want to be pedantic, you
can claim that electrons with a positive charge aren't really
electrons.

Of course positrons aren't electrons. The two are opposites, and if they
contact each other, they annihilate each other. Two electrons don't
annihilate each other.

In either case, what's the object's equivalent for "electric charge"?

I never said that position was the *only* property of electrons. They have
electric charge, they have spin, they have rest mass. But all these
properties are precisely, exactly the same from one electron and another.
Likewise instances of object() have a rich, object-oriented structure --
dir(object()) returns a list with twelve items -- but every instance is
identical.

Please don't try to get into the whole bosons versus fermions argument, or
bring up quantum mechanics. We'll only get even more confused. I don't
even want to hear the words "kinetic energy". It's only an analogy.

 

[Steven D'Aprano]

If two objects ARE the same value, then they should be the same
object.

You are assuming that values are unique, and that therefore is X "is" (in
the English sense, not the Python sense) some value, then no other thing Y
can also be the same value. I simply reject that interpretation: I see
nothing wrong with allowing two or more objects to be distinct objects and
yet be the same value.

Two physical copies of the same book "are the same" (are equal) if they
have the same words in the same order in the same typeface on the same
kind of paper, even if they came out of different printing presses on
different days.

I don't claim that the same many-to-many relationship between value and
object *must* hold, in either real life or Python, merely that it *can
and sometimes does* hold.

e.g. Borg instances all have the same value, even though they have
different identity. NaN floats are supposed to compare unequal even with
themselves. This may even be an implementation detail:
False

Since the 2000 on the left has different identity from the 2000 on the
right, do you wish to argue they have different values? I imagine not.
Neither would I.

I also will comfortably use the term "the object has the value foo" when I
wish to distinguish between object and value, or when the object is
mutable, or just whenever I feel like it. I don't think it usually matters
whether we talk about the int 1 "being 1" or the int 1 "having the value 1".

Where it does matter is for abstract types like object(), because they
don't have any "concrete" value *other than their own internal state*.

I put "concrete" in scare quotes because I'm fully aware that numbers like
1, 4.6, or strings like "mary had a little lamb" are in fact abstract, not
concrete. One sheep is a concrete thing, one is abstract. But nonetheless,
we behave as if 1 was a concrete thing.

I'm also fully aware that the 1-ness that distinguishes the int 1 from the
int 2 is part of the object's internal state too. I don't mean to imply
that non-abstract classes like int must have something (what? who knows?)
over and above their own internal state. What I mean is that we humans
have a concept of (numbers) 1 and 2, and we can map the number 1 to the
int 1 to the byte 00000001. We have no such simple concept to make
abstract objects to.

In particular, if the value is mutable, and you
change one object that is some value you change the value, but the any
other objects that are that value are still the old value of the value
(um, I hope you know what I mena).

Something like this perhaps?

L = [1, 2, 3]
M = [1, 2, 3]
L is M
==> False
L == M
==> True

L.append(4)
L == M
==> False

I have no problem with that. Some objects are mutable and can change their
value, some are not. That's no different from having a byte in memory, and
flipping bits. It is the same *byte*, even though the value it has changes.