469,267 Members | 1,643 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,267 developers. It's quick & easy.

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

I was under the assumption that everything in python was a refrence...

so if I code this:
lst = [1,2,3]
for i in lst:
if i==2:
i = 4
print lst

I though the contents of lst would be modified.. (After reading that
'everything' is a refrence.)
so it seems that in order to do this I need to code it like:

lst = [1,2,3]
for i in range(len(lst)):
if lst[i] == 2:
lst[i]=4
print lst

Have I misunderstood something?

Jan 4 '06
161 6653
Steven D'Aprano wrote:
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
sc***********@acm.org
Jan 14 '06 #101
On 2006-01-14, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
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.
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.

--
Antoon Pardon
Jan 14 '06 #102
In article <43********@nntp0.pdx.net>,
Scott David Daniels <sc***********@acm.org> wrote:

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).
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
Jan 14 '06 #103
Fredrik Lundh wrote:
Bryan Olson wrote:

The identity is not, in itself, a part of the value.

Python doesn't query the object to determine it's type or identity, but it
always has to query the object to access the value.
>

A look at the C implementation of a typical object might help:

typedef struct {
int ob_refcnt;
struct _typeobject *ob_type; /* type */
... an unknown amount of stuff used to represent the value ...
} MyObject;

In CPython, the MyObject* pointer is the identity. The ob_refcnt field is a
CPython implementation detail. The ob_type field contains the type.


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 ?


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:
'hello'.__class__

<type 'str'>

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.
--
--Bryan
Jan 14 '06 #104
"Donn Cave" <do**@drizzle.com> writes:
|> 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 14 '06 #105
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson writes:
ru***@yahoo.com wrote:

The reason is that I am still trying to figure out
what a value is myself. Do all objects have values?
Yes. Can you justify this, other than by quoting the manual whose problems
caused this question to be raised in the first place?

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?
What the value of object()? A few weeks ago I turned
to that page for enlightenment, with the results I reported.
I think type 'object' has only one value, so that's it.

In that case, they should all be equal, right?
>object() == object()

False
Looks like they have different values to me.

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?
Or maybe an object is valueless, in spite of what the manual says.

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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 14 '06 #106
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 04:22:53 +0000, Donn Cave wrote:
|> 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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 14 '06 #107
Mike Meyer <mw*@mired.org> writes:
Whether the '==' operation conforms to your idea of what equality
means is unclear.


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.
Jan 14 '06 #108
On Sat, 14 Jan 2006 14:14:01 +0000, Antoon Pardon wrote:
On 2006-01-14, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
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.


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.

Jan 14 '06 #109
On Sat, 14 Jan 2006 17:33:07 -0500, Mike Meyer wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 04:22:53 +0000, Donn Cave wrote:
|> 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).
--
Steven.

Jan 14 '06 #110
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
Mike Meyer <mw*@mired.org> writes:
> 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?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 14 '06 #111
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 14:14:01 +0000, Antoon Pardon wrote:
On 2006-01-14, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 14 '06 #112
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 14 '06 #113
Quoth Mike Meyer <mw*@mired.org>:
| Paul Rubin <http://ph****@NOSPAM.invalid> writes:
|> Mike Meyer <mw*@mired.org> writes:
|>> > 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, do**@drizzle.com
Jan 15 '06 #114
On Sat, 14 Jan 2006 18:21:28 -0500, Mike Meyer wrote:
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
Mike Meyer <mw*@mired.org> writes:
> 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?


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:
distance_in_feet = 5
weight_in_milligrams = 5
distance_in_feet == weight_in_milligrams

True

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

Jan 15 '06 #115
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
distance_in_feet = 5
weight_in_milligrams = 5
distance_in_feet == weight_in_milligrams

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #116
Mike Meyer wrote:
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson writes:

ru***@yahoo.com wrote:
>The reason is that I am still trying to figure out
>what a value is myself. Do all objects have values?

Yes.

Can you justify this, other than by quoting the manual whose problems
caused this question to be raised in the first place?


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?


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.

>What the value of object()? A few weeks ago I turned
>to that page for enlightenment, with the results I reported.

I think type 'object' has only one value, so that's it.

In that case, they should all be equal, right?

>>object() == object()

False
Looks like they have different values to me.


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


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.
Maybe I was wrong, and the object's identity
is part of its abstract state.


Is abstract state always part of the value?


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

Or maybe an object is valueless, in spite of what the manual says.


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.


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.
--
--Bryan
Jan 15 '06 #117
On Sat, 14 Jan 2006 18:49:43 -0500, Mike Meyer wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
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.


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.

Jan 15 '06 #118
On Sat, 14 Jan 2006 18:26:41 -0500, Mike Meyer wrote:
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:
1+1 is 2 True 1000+1000 is 2000

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.

--
Steven.

Jan 15 '06 #119
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson writes:
>ru***@yahoo.com wrote:
>>The reason is that I am still trying to figure out
>>what a value is myself. Do all objects have values?
>Yes.
Can you justify this, other than by quoting the manual whose problems
caused this question to be raised in the first place?

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?

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.
>>What the value of object()? A few weeks ago I turned
>>to that page for enlightenment, with the results I reported.
>I think type 'object' has only one value, so that's it.
In that case, they should all be equal, right?
>>>object() == object()
False
Looks like they have different values to me.
Whether the '==' operation conforms to your idea of what equality
means is unclear.

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.


Ok, so the objects identity is not it's value. Otherwise, the claim
"the type object has only one value" would be false.
Maybe I was wrong, and the object's identity
is part of its abstract state.

Is abstract state always part of the value?

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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #120
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
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):
dir(object) == 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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #121
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 18:26:41 -0500, Mike Meyer wrote:
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 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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #122
Steve Holden <st***@holdenweb.com> wrote:
...
3. If two objects are equal with "==", does that
mean their values are the same?


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
Jan 15 '06 #123
al***@mail.comcast.net (Alex Martelli) writes:
Steve Holden <st***@holdenweb.com> wrote:
...
> 3. If two objects are equal with "==", does that
> mean their values are the same? 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".


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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #124
Alex Martelli wrote:
Steve Holden <st***@holdenweb.com> wrote:
...
3. If two objects are equal with "==", does that
mean their values are the same?


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

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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 15 '06 #125
Steve Holden <st***@holdenweb.com> writes:
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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #126
On Sat, 14 Jan 2006 23:21:14 -0500, Mike Meyer wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
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):
dir(object) == 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 <type 'object'> object()

<object object at 0xf705d3b8>

Python can tell them apart, and so can we.

--
Steven.

Jan 15 '06 #127
On Sat, 14 Jan 2006 23:26:40 -0500, Mike Meyer wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 18:26:41 -0500, Mike Meyer wrote:
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 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.
x = 2000
y = 1000 + 1000
x is y False x == y
True

This causes me no trouble at all. Two instances of the same value, no big deal.
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?


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.

Jan 15 '06 #128
On Sun, 15 Jan 2006 06:08:43 +0000, Steve Holden wrote:
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?
--
Steven.

Jan 15 '06 #129
Steven D'Aprano wrote:
On Sun, 15 Jan 2006 06:08:43 +0000, Steve Holden wrote:

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?

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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 15 '06 #130
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 23:21:14 -0500, Mike Meyer wrote:
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 <type 'object'> object() <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.
isinstance(object, object)

True
<mike

--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #131
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 23:26:40 -0500, Mike Meyer wrote:
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?

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #132
Mike Meyer wrote:
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson <fa*********@nowhere.org> writes:

Mike Meyer wrote:

>Bryan Olson writes:
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?
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?


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

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.


The term "data type" implies instances have data; is it clear
enough that a datum is 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 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.

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.


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'.
Maybe I was wrong, and the object's identity
is part of its abstract state.

Is abstract state always part of the value?


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?


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

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.


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'?
--
--Bryan
Jan 15 '06 #133
Bryan Olson wrote:
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:
>>> 'hello'.__class__ <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 foo(object): ... __class__ = "oops"
... f = foo()
type(f) <class '__main__.foo'> f.__class__

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

Jan 15 '06 #134
On Sun, 15 Jan 2006 03:11:27 -0500, Mike Meyer wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 23:26:40 -0500, Mike Meyer wrote:
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? 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."


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.

Jan 15 '06 #135
On Sun, 15 Jan 2006 10:48:22 +0100, Fredrik Lundh wrote:
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:
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?

None is a singleton, so it is meaningless to ask about two instances of
NoneType. How about this?
class Empty: .... pass
.... id(Empty()) -151107636 type(Empty())

<type 'instance'>

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

--
Steven.

Jan 15 '06 #136
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).

(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?
class Empty: ... pass
... id(Empty()) -151107636 type(Empty()) <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
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.

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

</F>

Jan 15 '06 #137
Alex Martelli wrote:
Steve Holden <st***@holdenweb.com> wrote:
...
3. If two objects are equal with "==", does that
mean their values are the same? 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".

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.
Jan 15 '06 #138
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sun, 15 Jan 2006 03:11:27 -0500, Mike Meyer wrote:
Steven D'Aprano <st***@REMOVETHIScyber.com.au> writes:
On Sat, 14 Jan 2006 23:26:40 -0500, Mike Meyer wrote:
> 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?
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."

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #139
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson <fa*********@nowhere.org> writes:
Mike Meyer wrote:
Bryan Olson <fa*********@nowhere.org> writes:
>Mike Meyer wrote:
>>Bryan Olson writes:
>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?
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?

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

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?
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 fact that general principles and results depend on each
object having a value implies they must.


*What* general principles? *What* results?
> 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.

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

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


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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 15 '06 #140
Fredrik Lundh wrote:
Bryan Olson wrote:

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.


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?

[...]Python queries objects for their types; it's now a user-visible feature:
>>> 'hello'.__class__

<type 'str'>

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...d_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.
--
--Bryan

Jan 15 '06 #141
On Sun, 15 Jan 2006 12:14:16 +0100, Fredrik Lundh wrote:
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 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.

--
Steven.

Jan 15 '06 #142
Bryan Olson wrote:
Python queries objects for their types; it's now a user-visible feature:

>>> 'hello'.__class__
<type 'str'>

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.


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>

Jan 15 '06 #143
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.
[...]
The fact that general principles and results depend on each
object having a value implies they must.


*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.
--
--Bryan
Jan 15 '06 #144
Quoth "Fredrik Lundh" <fr*****@pythonware.com>:
| 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, do**@drizzle.com
Jan 15 '06 #145
Donn Cave wrote:
| > 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>

Jan 15 '06 #146
Mike Meyer <mw*@mired.org> writes:
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?


a==b simply means that a.__eq__(b) returns True.
Jan 15 '06 #147
[Alex Martelli]
....
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.

[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 ;-).
Jan 16 '06 #148
Op 2006-01-14, Steven D'Aprano schreef <st***@REMOVETHIScyber.com.au>:
On Sat, 14 Jan 2006 14:14:01 +0000, Antoon Pardon wrote:
On 2006-01-14, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
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.


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
Jan 16 '06 #149
Op 2006-01-15, Steven D'Aprano schreef <st***@REMOVETHIScyber.com.au>:
On Sun, 15 Jan 2006 12:14:16 +0100, Fredrik Lundh wrote:
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
Jan 16 '06 #150

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.