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

[Mike Meyer]

Are not hard to find.

Well, Google didn't turn anything up. On the other hand, "object" and
"value" are pretty poor terms to google with. Maybe you can suggest
better ones?

In Niklaus Wirth's /Algorithms + Data
Structures = Programs", the first section after "introduction"
"The concept of data type".

It's been a few decades since I read that, but I don't recall anything
that prohibited a valueless instance. My copy is in storage, so I
can't really double check it. Care to quote the relevant segment that
says that objects have to have a value?

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.

I obviously disagree that it's too obvious to state. Just because most
instances of objects have a value doesn't necessarily mean that every
instance of an object has a value. The discussion on these wikipedia
pages don't say anything that would imply that an object must have a
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.

But we're not talking about C, we're talking about Python.

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

Ok, so the objects identity is not it's value. Otherwise, the claim
"the type object has only one value" would be false.

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

So are you now claiming that all instances of object have different
values, as they all have different identities?

The concept of a valueless object is inconsistent with a great deal
material.

Another completely unsupported pronouncement. *What* material? Come
on, give me *explicit* references. At the very least, provide or point
to a definition of type that makes it clear that a type for which you
can have instances *has* to have values.

<mike

 

[Mike Meyer]

Likewise instances of object() have a rich, object-oriented structure --
dir(object()) returns a list with twelve items -- but every instance is
identical.

That's because all the things in dir(object()) are also in dir(object):
True

So those properties of object() are all identical because they're
really properties of object. If you define an object() by those
properties, you have to conclude that object is itself an instance of
object().

<mike

 

[Mike Meyer]

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 would say that's a valid definition of value.

I have no problem with that. Some objects are mutable and can change their
value

If the object *is* the value, how can it change to be a different
value without also changing to be a diffent object?

<mike

 

[Alex Martelli]

Almost universally, yes, although if you know enough about how the
interpreter works "under the hood" you can define the response of
instances of your own classes to the "==" operator (by defining their
__eq__ method), and even define a class whose instances aren't equal to
anything, even to themselves!

Hmmm... now this may be just be, but I'm quite vary of saying that,
since 1 == 1.0 == 1.0+0j, those three objects's values "are the same".

"Are equal", sure. But I intuitively see "being the same" as a stronger
condition than "being equal".

In mathematics, 1 is not "the same" as 1.0 -- there exists a natural
morphism of integers into reals that _maps_ 1 to 1.0, but they're still
NOT "the same" thing. And similarly for the real-vs-complex case.

Python may differ -- try using those "equal but not the same numbers" as
keys into the same dict, and see. One of the few *surprises* I ever got
from Python...!-)

((I don't think this violates the "introduce no complexity that doesn't
help understanding" rule -- I think the 1==1.0 case is important!))


Alex

 

[Mike Meyer]

Hmmm... now this may be just be, but I'm quite vary of saying that,
since 1 == 1.0 == 1.0+0j, those three objects's values "are the same".

For even more fun, consider 1.0 == 1 == decimal.Decimal('1.0').

"Are equal", sure. But I intuitively see "being the same" as a stronger
condition than "being equal".

When you say "being the same", I think "identity". But that's not
right either.

In mathematics, 1 is not "the same" as 1.0 -- there exists a natural
morphism of integers into reals that _maps_ 1 to 1.0, but they're still
NOT "the same" thing.

But what makes them different isn't attached to *them* - it comes with
the group/field they are part of. If I give you a mathematical 1 in
isolation, you can't tell if it's a real, an integer, a counting
number, or a member of Z-sub-n.

((I don't think this violates the "introduce no complexity that doesn't
help understanding" rule -- I think the 1==1.0 case is important!))

I do too. But I also think that Python's number types are somewhat
dodgy, and we might be better off if we ignore them for now. After we
get things straightened out for the other types, we can worry about
numbers.


<mike

 

[Steve Holden]

Hmmm... now this may be just be, but I'm quite vary of saying that,
since 1 == 1.0 == 1.0+0j, those three objects's values "are the same".

"Are equal", sure. But I intuitively see "being the same" as a stronger
condition than "being equal".

In mathematics, 1 is not "the same" as 1.0 -- there exists a natural
morphism of integers into reals that _maps_ 1 to 1.0, but they're still
NOT "the same" thing. And similarly for the real-vs-complex case.

Python may differ -- try using those "equal but not the same numbers" as
keys into the same dict, and see. One of the few *surprises* I ever got
from Python...!-)

((I don't think this violates the "introduce no complexity that doesn't
help understanding" rule -- I think the 1==1.0 case is important!))

Whether it violates the rule or not it's a welcome addition, as was Bengt's.

I just wish Mike Meyer and Steven D'Aprano were close enough that you
could bang their heads together. In the same playground, perhaps?

regards
Steve

 

[Mike Meyer]

I just wish Mike Meyer and Steven D'Aprano were close enough that you
could bang their heads together.

We might be. But the results would probably be catastrophic for the
surrounding area.

<mike

 

[Steven D'Aprano]

That's because all the things in dir(object()) are also in dir(object):

True

You are correct, of course, but your "proof" that you are correct is
bogus. All that your experiment shows is that the list of strings returned
by dir() is identical for the instance object() and the class object. Now,
you and I are both perfectly capable of using our knowledge of Python to
draw the obvious conclusion, but that isn't necessarily true for all
class/instance pairs. Here is a simple example (no doubt you can think of
simpler, and more complex, examples):

class pseudo_object:
def parrot(self):
return "Norwegian Blues have beautiful plumage."
parrot = classmethod(parrot)
def __init__(self):
self.parrot = lambda: "Nobody expects the Spanish Inquisition!"

And yet dir() reports the same signature for pseudo_object class and
instances.

In fact, we could imagine some other implementation of Python, BogoPython
perhaps, where object instances didn't inherit their methods from the
object class. On initialization, a factory function populated each
instance with all the methods it needed, which shared name and
functionality with the methods in the class, but not code. Potentially,
each instance method could have a unique implementation.

So those properties of object() are all identical because they're
really properties of object. If you define an object() by those
properties, you have to conclude that object is itself an instance of
object().

In this specific case, object instances get their properties from the
class, but your conclusion doesn't follow. The easiest way to tell this is
to ask, can we distinguish the object class (type) from an object
instance? The answer is, yes we can:
<object object at 0xf705d3b8>

Python can tell them apart, and so can we.

 

[Steven D'Aprano]

I would say that's a valid definition of value.

Perhaps it is, in some contexts. But I dispute that it is true in all
contexts. It depends on whether you CHOOSE to demand that values are
unique or not.
True

This causes me no trouble at all. Two instances of the same value, no big deal.

If the object *is* the value, how can it change to be a different value
without also changing to be a diffent object?

Because that's what they do.

Think of it this way: objects are the memory location, the value is the
particular pattern of bits at that memory location. Just because you flip
a couple of bits at location N, changing the value, the location doesn't
change.

 

[Steven D'Aprano]

I just wish Mike Meyer and Steven D'Aprano were close enough that you
could bang their heads together. In the same playground, perhaps?

Well, after such a deeply-reasoned, well-explained refutation of my
position, what can I do but admit that everything I said was clearly wrong
and Steve Holden is right?

 

[Steve Holden]

Well, after such a deeply-reasoned, well-explained refutation of my
position, what can I do but admit that everything I said was clearly wrong
and Steve Holden is right?

I wasn't trying to refute your position, nor Mike's, but to imply that I
wished you would both take what appeared to have become an essentially
private disagreement to a private channel.

regards
Steve

 

[Mike Meyer]

In this specific case, object instances get their properties from the
class, but your conclusion doesn't follow. The easiest way to tell this is
to ask, can we distinguish the object class (type) from an object
instance? The answer is, yes we can:
<object object at 0xf705d3b8>

Yes, but you're not looking at properties of the object, but rather of
the type of the object.

And for what it's worth, object is an instance of object.
True


<mike

 

[Mike Meyer]

Because that's what they do.
Think of it this way: objects are the memory location, the value is the
particular pattern of bits at that memory location. Just because you flip
a couple of bits at location N, changing the value, the location doesn't
change.

Ok. So when you say "the object is the value", you're *really* saying
"the memory location is the pattern of bits it holds." Except that a
memory location is an address, which is a pattern of bits. In
general, this won't be the same pattern of bits as the memory location
holds. So you're actually claiming that an object is two different
patterns of bits at the same time.

<mike

 

[Bryan Olson]

Well, Google didn't turn anything up. On the other hand, "object" and
"value" are pretty poor terms to google with. Maybe you can suggest
better ones?

Didn't I? "Type", or "data type" or "datatype", plus "abstract
data[optional-space]type.

It's been a few decades since I read that, but I don't recall anything
that prohibited a valueless instance.

The term "data type" implies instances have data; is it clear
enough that a datum is a value?

I obviously disagree that it's too obvious to state. Just because most
instances of objects have a value doesn't necessarily mean that every
instance of an object has a value.

The fact that general principles and results depend on each
object having a value implies they must.

> The discussion on these wikipedia
pages don't say anything that would imply that an object must have a
value.



But we're not talking about C, we're talking about Python.

You seemed to disagree when I said "the logic of 'types'
is reasonably well-defined in the discipline". If you're
just talking about Python, then the Python Language
Reference is right simply by status.


[...]

Ok, so the objects identity is not it's value.
Right.

Otherwise, the claim
"the type object has only one value" would be false.

I'm still not sure that there's only one value for
objects of type 'object'.

So are you now claiming that all instances of object have different
values, as they all have different identities?

No, I had said I was unsure whether objects of type 'object'
know their identities, as Python defines them. (I think they
do not.)

Another completely unsupported pronouncement. *What* material? Come
on, give me *explicit* references.

My textbooks are in storage too, but you'll find plenty if
you look. Remember learning about "call by value"? Did they
have to deal with objects without a value to pass?

Discussion involving an object's value would have to be rewritten
to cover the case of objects that don't have one. Is a valueless
object mutable or immutable? Let's see; the Reference says:

Objects whose value can change are said to be mutable;
objects whose value is unchangeable once they are created
are called immutable.

Your valueless objects break the definitions. The Ref says
"An object's mutability is determined by its type" so it
must have some mutability status to determine. Want to
re-work the literature to cover your special case?

Got any references yourself? Where's the literature on typed
objects that don't have values?

> At the very least, provide or point
to a definition of type that makes it clear that a type for which you
can have instances *has* to have values.

Did the references make clear to you that this usage of 'type'
means 'data type'?

 

[Fredrik Lundh]

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. the identity and type are not part of the value. the
type controls *how* to access the value, and needs to be known *before*
you can access the value.

(CPython solves this by letting an object reference point to a structure
with two known fields and an opaque value block; other implementations
may use other ways to associate identities and types with references.
A Python runtime that uses a copying garbage collector must store the
object identity separately as well, since the identity be stable even if
the reference changes. A runtime that uses references that don't fit
in integers may have to do the same.)

I don't think usage of "query" is the issue.

If you define "query an object" as "query an objects value via the type
mechanism" (which is what I had in mind), the rest of your argument is
just plain wrong. If you define it as "look inside some data structure used
by the computer", further discussion is meaningless, since all terms can
then mean anything.

Python queries objects for their types; it's now a user-visible feature:

<type 'str'>

To get an object's type, use type(x). This has always been a user-
visible feature (along with id(x)).

__class__ is simply a property on the object baseclass that returns
type(self) for new-style classes. Overriding __class__ doesn't change
the behaviour of the type function, and doesn't change the object's
type:
... __class__ = "oops"
... 'oops'

If type queried the object, type(f) and f.__class__ would have returned
the same thing.

(with old-style classes, all instances belong to the instance type, and
type(x) and x.__class__ give different results from the start)

Python would still be duck-typed and the type would still be a
property of the object.

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). What the documentation and I are saying is that it's not a
part of the object's *value*.

An object's identity, type, and value are three different and distinct things
(or "properties", if you prefer). End of story.

</F>

 

[Steven D'Aprano]

Ok. So when you say "the object is the value", you're *really* saying
"the memory location is the pattern of bits it holds."

No. You seem to have trouble with analogies. My apologies for not making
it clearer: I should have said, by analogy, the relationship between
mutable objects and their value is equivalent to the relationship between
a memory location and the bit pattern at that location.

Except that a
memory location is an address, which is a pattern of bits. In general,
this won't be the same pattern of bits as the memory location holds. So
you're actually claiming that an object is two different patterns of
bits at the same time.

I'm not claiming that at all, but I don't have any problem with the
concept of certain objects being two or more things simultaneously.
Prince Charles, for example, is simultaneously Queen Elizabeth's son,
Diana's widower, Harry and William's father, Camilla's husband, and many
more things besides.

It isn't common for programming data to have multiple values
simultaneously, but it does happen: a certain value can be a pointer to a
memory location and an integer, or a numeric value and a character.

 

[Steven D'Aprano]

an object's identity, type, and value are three different
and distinct things. the identity and type are not part of the value. the
type controls *how* to access the value, and needs to be known *before*
you can access the value.

(Not arguing, just trying to clarify your point.)

I'm sick of arguing about object, let's use a different example:
<type 'NoneType'>

What's the value of None? Would you say "it has no value" or "it's value
is None" or something else?

None is a singleton, so it is meaningless to ask about two instances of
NoneType. How about this?
.... pass
.... <type 'instance'>

Do two instances of Empty have the same value, or is the question
meaningless?

 

[Fredrik Lundh]

I'm sick of arguing about object, let's use a different example:

<type 'NoneType'>

What's the value of None? Would you say "it has no value" or "it's value
is None" or something else?

it has no value (or if you prefer, the set of values is empty).

(unless you're talking about None-the-not-quite-but-almost-keyword, which
always evaluates to the same None object, unless you hack the __builtin__
namespace).

the None object has an identity and a type.

None is a singleton, so it is meaningless to ask about two instances of
NoneType. How about this?

... pass
...
<type 'instance'>

Do two instances of Empty have the same value, or is the question
meaningless?

Things are a bit mixed up wrt. old-style classes (because they're implemented
in terms of true objects), but if you make that
... __slots__ = []
...

it should be clear that instances of this class have no value (or if you prefer,
the set of values is empty for all instances), and cannot have one either.

all Empty objects have an identity and a type, though.

</F>

 

[Xavier Morel]

Hmmm... now this may be just be, but I'm quite vary of saying that,
since 1 == 1.0 == 1.0+0j, those three objects's values "are the same".

"Are equal", sure. But I intuitively see "being the same" as a stronger
condition than "being equal".

One could check use Common Lisp's "=", "eq" and "eql" operators (which
respectively check for "being equal" as in "having the same set of
values", "being very equal" as in "having the same set of values and the
same type" and "being the same" as in being exactly the same object e.g.
identity equality)

In mathematics, 1 is not "the same" as 1.0 -- there exists a natural
morphism of integers into reals that _maps_ 1 to 1.0, but they're still
NOT "the same" thing. And similarly for the real-vs-complex case.

I disagree here, 1 and 1.0 are the same mathematical object e.g. 1 (and
the same as "1+0i"), the difference due to notation only makes sense in
computer science where integers, real and complex ensembles are disjoin.
In mathematics, Z is included in IR which is included in C (note: this
is not mathspeak, but I have no idea how to say it in english), and this
notation -- at best -- merely determines the ensemble you're currently
considering.

There is no "natural morphism" of integers into reals because there is
no mathematical difference between integers and reals, the real ensemble
is merely a superset of the integers one.

Or so it was last time i got a math course.

 

[Mike Meyer]

No. You seem to have trouble with analogies. My apologies for not making
it clearer: I should have said, by analogy, the relationship between
mutable objects and their value is equivalent to the relationship between
a memory location and the bit pattern at that location.

No, I don't have any trouble with analogies. I'm just carrying it to
make the point that *I* want to make, rather than stopping at the
point that you want to make.

It isn't common for programming data to have multiple values
simultaneously, but it does happen: a certain value can be a pointer to a
memory location and an integer, or a numeric value and a character.

Yup, and they're all represented by the same bit pattern. I've got no
problem with that. It's perfectly correct to say that that bit
pattern *is* all those things. On the other hand, it's not correct so
say that the memory location - or the object - that those bit patterns
reside in *is* those those. It isn't - it just holds them.

<mike