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

[Mike Meyer]

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.

You mentioned those in close connection with Wickipedia, so I only
checked there. In retrospect, those probably don't work well, as we've
already established that datatypes don't necessarily have to have
values.

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

Actually, what "data type" implies to me is that data have a type. But
skip that for now - what's the data that goes along with an instance
of object?

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

*What* general principles? *What* results?

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.

That my repeated requests for a definition of "type" (or "object) have
never been answered suggest very strongly to me that the logic of
types is not well-defined.

And I'm trying to find out if there is any justification for the
statement made in the Python Programing language. If there's some good
reason that valueless objects can't (or shouldn't) exist in general,
that will do. If there's some reason they can't (or shouldn't) exist
in Python, that will do - though I'm also interested in the general
question.

What I'm *not* interested in is examples from other programming
languages. That they fail to let you have objects without values no
more proves that objects can't have values than Python not letting you
take the address of a variable provesd that variables can't have
addresses.

[...]

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'.

Well, if you can identify the set the values are drawn from, that
would go a long way towards settling that issue.

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?

No. But in Python, "call by reference" has to deal with objects
without a reference to pass. So what?

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?

So you're claiming that "all objects have values" is a convenience,
like "x raised to the power 0 is 1"?

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

Ain't got none. On the other hand, I'm not trying to prove that such
objects exist. I'm trying to find out if there's any justification for
claiming that they don't exist.

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

Yes - but we've already established that some data types don't have
values associated with them, so that doesn't really do much
good.

<mike

 

[Steven D'Aprano]

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.

But that's the thing, it isn't clear to me at all that they have no value.
Does the empty string have a value? I would say yes. How about {} and []?
Again, I would say yes. So why do None and Empty() have no value?

It took mathematicians centuries to stop arguing about whether 0 is a
number or not, and then they argued whether or not 1 is a number. And
then when they settled that both 0 and 1 are numbers, they argued
whether the empty set counted as a set or not. So I'm not surprised that
we don't see eye-to-eye here.

I think part of the reason is that you are thinking at one abstract level,
where objects have a type, an identity, and "everything else", and you
DEFINE that "everything else" as "value". By that definition, if there is
nothing else, then there is no value. I can understand that, but I also
think that there is a different sense of "value" for which it makes sense
to include type and/or identity as part of the value. The alternative, it
seems to me, is to conclude that empty strings, dicts, lists and tuples
all are equally valueless, and I don't think that is a good idea.

The downside of my definition of "value" is that it is fuzzy and depends
on context. Often we want to exclude type (so that 1 and 1.0 have the
same value), we almost always want to exclude identity (so that [1,2] and
[1]+[2] have the same value), but there are enough exceptions to make
things interesting.

 

[Bryan Olson]

Bryan Olson wrote:




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?

[...]

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.

 

[Fredrik Lundh]

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.

so the object in my example has the type "oops" ?

The story continued.

what story? looks like kookery to me. I recommend moving this thread
to comp.lang.funny.snake.farm

</F>

 

[Bryan Olson]

Mike Meyer wrote:
[...]

Actually, what "data type" implies to me is that data have a type. But
skip that for now - what's the data that goes along with an instance
of object?

Again, I'm not an expert on 'object'. When a type has
a single value instances can take, the value is simply
defined as the single instance of the type.


[...]

*What* general principles? *What* results?

Those that refer to the value of an instance without
covering the special-case of valueless objects. You've
seen some, and could not cite anything that includes
the case of valueless instances.

Mathematical methods break. In reasoning about the
correctness of implementations, we define functions
(mathematically, not in code) that map representations
to the values they represent. To allow some instances
to be valueless, we'd then need mathematical variables
that range over non-values.

That my repeated requests for a definition of "type"
> (or "object) have never been answered

See the first sentence of the Wikipedia article on data
type.


[...]

So you're claiming that "all objects have values" is a convenience,
like "x raised to the power 0 is 1"?

All definitions are a convenience. Not special-casing
addition to define 2+2 to be five is a convenience that
makes our results cleaner.


[...]

Ain't got none. On the other hand, I'm not trying to prove that such
objects exist. I'm trying to find out if there's any justification for
claiming that they don't exist.

It's the reference, it gets to decide.

 

[Donn Cave]

Quoth "Fredrik Lundh" <[email protected]>:
| Steven D'Aprano wrote:
|
| > I'm sick of arguing about object, let's use a different example:
| >
| > >>> id(None)
| > 135289128
| > >>> type(None)
| > <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).

Dang, I would have said it does have a value. For one thing, in

if a:
print 'more or less True'
else:
print 'evidently not'

None doesn't follow the default, so it seems like "if" has discovered
some sort of value in there.

(But of course in any case, whether this is a value or not a value, the
value of the question is certainly in question.)

Donn Cave, (e-mail address removed)

 

[Fredrik Lundh]

| > 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).

Dang, I would have said it does have a value.

For one thing, in

if a:
print 'more or less True'
else:
print 'evidently not'

None doesn't follow the default, so it seems like "if" has discovered
some sort of value in there.

the "if" statement happens to use object identity to determine truth values
for certain special objects, including None:

int
PyObject_IsTrue(PyObject *v)
{
int res;
if (v == Py_True)
return 1;
if (v == Py_False)
return 0;
if (v == Py_None)
return 0;
/... query object .../
}

in the more general case, it's up to the object's type implementation to deter-
mine its "truth value", in response to a __nonzero__ or __len__ query.

maybe we need a new word for "virtual values" that are not really part of an
object's internal state ?

</F>

 

[Paul Rubin]

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

a==b simply means that a.__eq__(b) returns True.

 

[Tim Peters]

[Alex Martelli]
....
[Xavier Morel]

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.

This all depends on which math course you last took ;-) You have more
a physicist's view here. The simplest case is real versus complex,
where even a physicist <wink> can accept that a complex number,
formally, is an ordered pair of real numbers. From that view, it's
almost obviously not possible that a complex number could be "the same
object" as a real number. For example, 1+0i is formally the ordered
pair <1.0, 0.0>, but the real 1.0 is just the real 1.0. If you'll
grant that a real number is never itself an ordered pair of real
numbers, then the intersection between the complex and real numbers is
necessarily empty.

At lower levels of the "numeric tower" you have in mind, the formal
difference is more extreme, not less. The natural numbers
("non-negative integers") are often defined in terms of von Neumann
ordinals, so that natural number N "is" the set of all natural numbers
less than N (0 "is" the empty set, 1 "is" the set containing the empty
set, 2 "is" the set containing the empty set and the set containing
the empty set, ...), while defining reals as either Dedekind cuts or
Cauchy sequences requires elaborate formal machinery.

Does it matter? To foundational mathematicians, certainly. Luckily,
in a computer all numerics suck, so who cares ;-).

 

[Antoon Pardon]

Yes. And this is a problem why?

It is not about problems, it is about precision of language.
You can't state that an object *is* a value if different
values can be associated with the same object.

Some values are fixed, and some values are
changeable.

No values are not changeable. Objects (through mutation)
aquiring a new value is not the same as changable values.

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?

No values don't change. Objects can mutate and thus can aquire a new
value. Yes we often use language that states: The value changes, but
that is just a shortcut, just as we speak of hearing a train instead
of hearing the sound of a train.

If you say an object is a value, that would imply that two lists
with the same value would also be the same list.

 

[Antoon Pardon]

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

class Empty(object):

... __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.

But that's the thing, it isn't clear to me at all that they have no value.
Does the empty string have a value? I would say yes. How about {} and []?
Again, I would say yes. So why do None and Empty() have no value?

It took mathematicians centuries to stop arguing about whether 0 is a
number or not, and then they argued whether or not 1 is a number. And
then when they settled that both 0 and 1 are numbers, they argued
whether the empty set counted as a set or not. So I'm not surprised that
we don't see eye-to-eye here.

I think part of the reason is that you are thinking at one abstract level,
where objects have a type, an identity, and "everything else", and you
DEFINE that "everything else" as "value". By that definition, if there is
nothing else, then there is no value. I can understand that, but I also
think that there is a different sense of "value" for which it makes sense
to include type and/or identity as part of the value. The alternative, it
seems to me, is to conclude that empty strings, dicts, lists and tuples
all are equally valueless, and I don't think that is a good idea.

The downside of my definition of "value" is that it is fuzzy and depends
on context. Often we want to exclude type (so that 1 and 1.0 have the
same value),

We don't need to. We could look at == as being an "is equivallent with"
relationship. So 1 and 1.0 are not the same (value) but they are
equivallent (in an arithmetic context).

 

[Antoon Pardon]

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

I would say they are two different values that are equivallent
in a lot of ways.

 

[Antoon Pardon]

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

I would say: "is equivallent with".

 

[Boris Borcic]

Mike Meyer wrote :

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

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.True

MMhhhh, painful

 

[Bengt Richter]

a==b simply means that a.__eq__(b) returns True.

That's one possibility, but I guess __eq__ might not necessarily
even have to be defined (too lazy to set up the new-style class test ;-):
... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
... ... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
... A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Regards,
Bengt Richter

 

[Steven D'Aprano]

... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
...
... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
...
A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Why are A().__eq__ and B().__eq__ both being called twice?

 

[Boris Borcic]

Tim Peters a écrit :

[Alex Martelli]
...

- but does there exists any sense of "mathematics object identity"
that's not built out of similar maps ? IOW, if - abstracting from your
example - I admit as a rule that is sufficient to deny identity, to
point out that two objects are "merely" related by a natural map, isn't
it then the case that I can display an infinite quantity of *distinct*
clones of any mathematical object or structure that I can think of ?

Smallscale python illustration :

False

[Xavier Morel]

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.

Well, how do you know there should be a difference between
(a) "(there exists) a natural morphism from A to B"
(b) "A is a subset of B"
? To paraphrase you : "the 'natural morphism' ensemble is merely a
superset of the 'subset/superset' one"

More to the point, where you view really breaks is when two incompatible
extensions of the number tower are possible, like what happens with
complex numbers and surreal numbers, which are both rich extensions of
real numbers. Or real numbers and transfinite cardinals, viewed both as
extending natural numbers.

This all depends on which math course you last took ;-)

I often wonder whether young and adventurous minds could be more
efficiently seduced to mathematics by enlisting them to interstellar travel.

The idea goes thus. First note that by adjusting (natural) language
courses one may end up with home-grown pupils equivalent to pupils taken
from another continent; for instance you may teach arab to young
americans and obtain something more in the likeness of an arab.

Then argue that by adjusting the mathematics curriculum, one may obtain
similar effects, but with displacements on the scale of interstellar
travel rather than intercontinental travel !

[Tim Peters]

You have more a physicist's view here. The simplest case is real versus complex,
where even a physicist <wink> can accept that a complex number,
formally, is an ordered pair of real numbers.

Well, I suppose you've heard of Paul Erdoes's notion of a "Supreme
Fascist" dictator of mathematics who owns a Book of All the Best Proofs ?

It's easy to extend Him with a -WarpDrive- method of the form "Any
teacher teaching A before B shall be sentenced to death".

The spacedrive effect would be obtained by an appropriate choices of A
and B divergent from our current habits. Of course one could expect many
choices to lead nowhere - or at least to rough rides. But, I surmise
that a promising and most fascinating pick would be A=real, B=complex.

....

in a computer all numerics suck,

Sets suck.

Cheers, BB

 

[Bengt Richter]

Why are A().__eq__ and B().__eq__ both being called twice?

I imagine it's trying the calls with args swapped or something like that.
Want to write a test and see? (Don't hold your breath if you're waiting for me to do it ;-)

Regards,
Bengt Richter

 

[Steven D'Aprano]

I imagine it's trying the calls with args swapped or something like that.
Want to write a test and see? (Don't hold your breath if you're waiting for me to do it ;-)

You already wrote a test. I can't think of any test I can write which
would give more information than yours. I'd like a test where I can see
the arguments which Python would apply to each method call, but I can't
think of any way to get those arguments inside the __getattr__ method.
Perhaps I'm not thinking hard enough.

(Actually writing __eq__ methods would defeat the purpose.)

There aren't that many possibilities. We can predict the other argument
from each call: if you call a method of A, the argument must be B and vice
versa. So it looks like Python is making the following calls:

A().__eq__(B)
B().__eq__(A)
B().__eq__(A)
A().__eq__(B)

followed by the unproblematic calls to __coerce__ and __cmp__.

What puzzles me is that after trying B.__eq__(A), it tries it again
immediately. It only calls coerce and cmp once with each set of args. What
am I missing?

 

[Bengt Richter]

Why are A().__eq__ and B().__eq__ both being called twice?

Looks like it has to do with trying stuff with arguments switched?
This shows call and argumenst to method for whichever attribute access
is allowed to succeed after a count of failures...
... global trial, which
... for which in xrange(9):
... print '\nwhich: %s'%which
... trial = 0
... A()==B()
... ... print '__eq__(%s(), %s())'%(nameof(x), nameof(y)); return False
... ... print '__cmp__(%s(), %s())'%(nameof(x), nameof(y)); return 0
... ... print '__coerce__(%s(), %s())'%(nameof(x), nameof(y)); return None
... ... def __getattr__(self, attr):
... global trial
... print '%s: A().%s'%(trial, attr)
... if trial!=which: trial+=1; raise AttributeError
... return globals()[attr].__get__(self, type(self))
... ... def __getattr__(self, attr):
... global trial
... print '%s: B().%s'%(trial, attr)
... if trial!=which: trial+=1; raise AttributeError
... return globals()[attr].__get__(self, type(self))
...
which: 0
0: A().__eq__
__eq__(A(), B())

which: 1
0: A().__eq__
1: B().__eq__
__eq__(B(), A())

which: 2
0: A().__eq__
1: B().__eq__
2: B().__eq__
__eq__(B(), A())

which: 3
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
__eq__(A(), B())

which: 4
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
__coerce__(A(), B())
4: B().__coerce__
__coerce__(B(), A())
4: A().__cmp__
__cmp__(A(), B())

which: 5
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
__coerce__(B(), A())
5: A().__cmp__
__cmp__(A(), B())

which: 6
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
6: A().__cmp__
__cmp__(A(), B())

which: 7
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
6: A().__cmp__
7: B().__cmp__
__cmp__(B(), A())

which: 8
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
6: A().__cmp__
7: B().__cmp__
Regards,
Bengt Richter