Sorry for the numpty question ...
How do you find the reference name of an object?
So if i have this
bob = modulename.objectname()
how do i find that the name is 'bob'
Oct 16 '08
275  12013 
Steve Holden wrote:
greg wrote:
>>Do you agree that it makes sense to talk about assigning
that value to something?
No. Why do you think that we are (mostly) careful to talk about binding
names and values instead?
That's an odd position to take, considering that the
Python docs use the word "assignment" all over the
place, and the language even has a statement known
as an "assignment statement".
The Python Language Reference has this to say about
assignment:
The following constructs bind names: formal parameters to functions, import
statements, class and function definitions (these bind the class or function
name in the defining block), and targets that are identifiers if occurring in
an assignment...
[ http://docs.python.org/reference/executionmodel.html]
What this suggests to me is that the reason the
Language Ref talks about binding is not because there's
anything wrong with the word assignment, but because
binding is a more general term. Assignment is one way
to perform binding, but there are other things that
perform binding as well.
But then various participants in this thread have
demonstrated an apparently infinite capacity to split hairs with the
presumed intention of proving themselves right and others wrong.
For my part, I'm not trying to "prove myself right",
I'm trying to be helpful by clearing up what seems to
me to be a misunderstanding about what the term
call-by-value implies. But it appears that some people
stubbornly refuse to have their misunderstandings
cleared up. :-)
That's how it looks from my end, anyway. No doubt from
the other end it looks like I'm the one being stubborn.
That's why I've been trying to inject some objectivity
by doing some research and finding authoritative
references to back up what I'm saying.
I'm learning things from all this, too. For example,
until recently I couldn't be sure I wasn't the only
person in the world who had thought of the idea of
defining call-by-value in terms of assignment rather
than copying. Turns out I'm not -- Backus et al, no
less, had exactly the same idea. And it seems they're
not the only ones, either -- more on that later.
--
Greg
Grant Edwards wrote:
I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...
Those people clearly know a great deal about Python,
and I respect them for that. However, that doesn't
necessarily make them authorities on programming
language terminology.
If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...
--
Greg
On Nov 13, 3:44*am, greg <g...@cosc.canterbury.ac.nzwrote:
Grant Edwards wrote:
I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...
Those people clearly know a great deal about Python,
and I respect them for that. However, that doesn't
necessarily make them authorities on programming
language terminology.
If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...
The authors of C# and Java can be considered authorities in the field
concerned. So authoritative, that if they want to redefine existing
terms, the masses must follow.
Fredrik Lundh wrote:
Python's definition of the word "value" can be found in the language
reference:
http://docs.python.org/reference/dat...lues-and-types
That whole passage is talking almost
exclusively about the value of an *object*:
Every object has an identity, a type and a value...
...possible values for objects of that type...
The value of some objects can change...
etc. etc. But we don't want to know about the value of
an object, we want to know about the value of an
*expression*. That section doesn't tell us. Nor does
it tell us that expressions don't *have* values. It
says nothing about expressions at all.
Using that definition, a Python expression yields an object, not an
object value.
And as I've said before, that's a perfectly fine viewpoint.
Because,
An assignment statement evaluates the expression list (remember that this can
be a single expression or a comma-separated list, the latter yielding a tuple)
and assigns the single resulting object to each of the target lists, from left
to right.
[ http://docs.python.org/reference/sim...signment_stmt]
and what it says about binding makes it clear that assignment
is a form of binding operation.
So it doesn't matter *what* you call the result of an expression
-- a value, an object, an object reference, or whatever -- the
differences all cancel out when you define assignment in a
corresponding way.
--
Greg
greg wrote:
If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...
Like Barbara Liskov, who's won tons of awards for her work on computer
science and programming languages, and who was among the first to
design, implement, and formally describe a language with *exactly* the
same evaluation semantics as Python? What did she and her co-authors
have to say about the calling semantics in their new language? Let's see:
"In particular it is not call by value because mutations
of arguments performed by the called routine will be
visible to the caller. And it is not call by reference
because access is not given to the variables of the
caller, but merely to certain objects."
Let's take that again, with emphasis:
"IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
of arguments performed by the called routine will be visible to
the caller. And IT IS NOT CALL BY REFERENCE because access
is not given to the variables of the caller, but merely to
certain objects."
"It is not". "And it is not".
But maybe they were just ignorant, and didn't really "get" how earlier
languages worked? Let's see what Liskov has to say about that:
"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages. Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."
Still think they didn't understand Algol's semantic model?
:::
But nevermind - the real WTF with threads like this one is the whole
idea that there are two and only two evaluation strategies to choose
from. That's a remarkable narrow-mindedness.
</F>
On Nov 12, 2:05*pm, Fredrik Lundh <fred...@pythonware.comwrote:
Python's definition of the word "value" can be found in the language
reference:
http://docs.python.org/reference/dat...lues-and-types
Using that definition, a Python expression yields an object, not an
object value.
There is no definition of value there, just an assertion that values
exist.
Fredrik Lundh wrote:
greg wrote:
>If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...
Like Barbara Liskov, who's won tons of awards for her work on computer
science and programming languages, and who was among the first to
design, implement, and formally describe a language with *exactly* the
same evaluation semantics as Python? What did she and her co-authors
have to say about the calling semantics in their new language? Let's see:
"In particular it is not call by value because mutations
of arguments performed by the called routine will be
visible to the caller. And it is not call by reference
because access is not given to the variables of the
caller, but merely to certain objects."
CLU reference manual. 1979 Google's searchable HTML version (apparently
from OCR of scan package as .pdf) with a few mis-conversions. http://64.233.169.104/search?q=cache...79-000225e.pdf
We call the argument passing technique call by sharing, because the
argument objects are shared between the caller and the called routine.
She later. in 1992, called it "pass by object" (below).
But maybe they were just ignorant, and didn't really "get" how earlier
languages worked? Let's see what Liskov has to say about that:
"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages. Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."
Still think they didn't understand Algol's semantic model?
The second quote come from
A History of CLU, by Barbara Liskov 1992 http://publications.csail.mit.edu/lc...LCS-TR-561.pdf
Python owes more to CLU than I realized.
"Assignment has a type-independent meaning with the heap approach;
x := e
causes x to refer to the object obtained by evaluating expression e."
"arguments are passed "by object"; the (pointer to the) object resulting
from evaluating the actual argument expression is assigned to the
formal. (Thus passing a parameter is just doing an assignment to the
formal.)"
Exactly described Python also.
"we wanted to treat built-in and user-defined types alike"
Achieved fully in 3.0. She notes a difference though: some built-in
types have literals. No user types do.
"We allow common operator symbols but these are only short forms for
what is really happening, namely a call on an operation using its full
t$o name. When the compiler encounters such a symbol, it "desugars" it
by following a simple rule: it produces t$o where t is the type of the
first argument, and o is the operation name associated with the symbol.
Thus "x + y" is desugared to "t$add(x, y)" where t is the type of x."
In CLU and Python, methods belong to the class/type rather than to the
instances (as in C++ she claims).
"""Not only is this approach simple and easy to understand, it applies
to both built-in and user-defined types uniformly. To allow sugars to be
used with a new type, the type definer need only choose the right
names for the operations. For example, to allow the use of +, he or she
names the addition operation "add." """
Also, CLU has exceptions that terminate and iterators used in for
statements.
Terry Jan Reedy
On Nov 12, 7:09 pm, George Sakkis <george.sak...@gmail.comwrote:
On Nov 12, 4:05 pm, Fredrik Lundh <fred...@pythonware.comwrote:
>greg wrote:
>It's not only misleading, it's also a seriously flawed reading of the
original text - the Algol 60 report explicitly talks about assignment
of *values*.
Do you agree that an expression in Python has a value?
Do you agree that it makes sense to talk about assigning
that value to something?
Python's definition of the word "value" can be found in the language
reference:
http://docs.python.org/reference/dat...lues-and-types
Quoting the relevant part:
"The value of some objects can change. Objects whose value can change
are said to be mutable; objects whose value is unchangeable once they
are created are called immutable."
Strictly speaking that's not a definition; it doesn't say what a value
is, only how it relates to objects. But regardless, according to this,
a Python value is what the rest of the world usually calls "state",
....snip...
That just pushes the question to, "what's state?" doesn't it?
Is a method part of an object's state (and hence "value"?)
Are an object's data attribute values part of it's state?
Are the values of a, b, and c different below?
a = int(1)
class myint(int): pass
b = myint(1)
c = myint(1)
c.foo = 2
I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python. ru***@yahoo.com wrote:
I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.
I noticed too. My try:
The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression. For
number objects, the number value. For collection objects, the objects
collected. For functions, the signature and function performed when called.
How is that?
Terry Jan Reedy
On Nov 13, 4:53 pm, Terry Reedy wrote:
ru***@yahoo.com wrote:
>I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.
I noticed too. My try:
The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression. For
number objects, the number value. For collection objects, the objects
collected. For functions, the signature and function performed when called.
How is that?
I am starting with the idea that "value" is what we call
whatever it is that is the difference between, for example,
the objects int(3) and int(4). While your definition
seems to be saying something similar it does not seem
very precise.
How would I use your definition to answer the following
questions?
* How does an object get a value?
* Can I create an object that has a value that
is the same as int(3) without somehow using an
int(3) object in its construction?
* Do all objects have values? (Ignore the Python
docs if necessary.)
* What is the value of object()?
* Does an object's behavior (methods) affect
its value?
* If two objects have different unrelated types
(i.e. not subclassed), are their values necessarily
different (regardless of how they print, or act
when used in an expression)?
* What if they aren't unrelated but one is a sub-
class of the other?
* Can one completely hide an object's value by
overriding methods?
* Can two objects have the same value, even if the
methods of one have been overridden to hide it's
value as completely as possible?
I wonder if all values come, directly or indirectly,
from "valued objects" created in the C-API?
Or perhaps value is some sort of useful but fundamentally
undefinable concept that disappears when looked at too
closely, leaving behind only state and behavior? ru***@yahoo.com wrote:
On Nov 13, 4:53 pm, Terry Reedy wrote:
>ru***@yahoo.com wrote:
>>I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.
I noticed too. My try:
The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression. For
number objects, the number value. For collection objects, the objects
collected. For functions, the signature and function performed when called.
How is that?
I am starting with the idea that "value" is what we call
whatever it is that is the difference between, for example,
the objects int(3) and int(4). While your definition
seems to be saying something similar it does not seem
very precise.
I think necessarily so, or rather, it can only be specific for each
class. In the formulation: an object has identify, class, and value,
class and value are separated. Others have said that type/class is a
universe of possible values and operations on those values. Each
instance has a particular value. 'Universe of possible values' is vague
until one gets specific. For some classes, the possible values are
rather complex.
How would I use your definition to answer the following
questions?
* How does an object get a value?
A Python interpreter, human or electronic, creates objects with values
as directed by Python code. How it does so is its private secret ;-).
The directive code includes literals, expressions, and some statements.
* Can I create an object that has a value that
is the same as int(3) without somehow using an
int(3) object in its construction?
Yes: 1 + 2
Yes: mpz(3) where mpz is multi-precision int class with same set of
possible values as Python ints.
??? 3.0
??? Fraction(3,1)
While Python sees these as *equal*, one could say they are not the same
because they indicate members of different (non-isomorphic) universes.
* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
Still, numbers, characters, and collections thereof of what code is
usually about.
* What is the value of object()?
Essentially none, other than bool(object()) == True.
Ditto for None, other than bool(None) == False.
Otherwise, None and object convey no information.
* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class. In those cases in which the class
of an object can be and is changed to another class, the interpretation
of the value/info of the instance could change and one might claim that
the effective value and hence the value of the object has changed and
hence the answer could be Yes. But this is extremely rarely done and I
could claim that this is a shortcut for creating a new object and
deleting the old.
* If two objects have different unrelated types
(i.e. not subclassed), are their values necessarily
different (regardless of how they print, or act
when used in an expression)?
No. See above Q. about int(3).
* What if they aren't unrelated but one is a sub-
class of the other?
Easier no than above.
* Can one completely hide an object's value by
overriding methods?
You tell me ;-)
Do you have an example that you were thinking of?
* Can two objects have the same value, even if the
methods of one have been overridden to hide it's
value as completely as possible?
I wonder if all values come, directly or indirectly,
from "valued objects" created in the C-API?
CPython creates objects with values in C functions. I presume most are
exposed in the API. But my definition is intentionally not specific to
any implementation.
Or perhaps value is some sort of useful but fundamentally
undefinable concept
Either yes or defined in terms of information or universes.
that disappears when looked at too closely
No.
Leaving behind only state and behavior?
State is a choice amoung possible states, which is to say, information.
Behavior is determined by class,
Terry Jan Reedy
On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote: ru***@yahoo.com wrote:
>On Nov 13, 4:53 pm, Terry Reedy wrote:
>>ru***@yahoo.com wrote:
I have yet to see any reasonable definition of a Python value in the
Python docs or elsewhere, despite the fact that a value is one of the
three defining characteristics of an object, a central concept in
Python.
I noticed too. My try:
The value of an object is the information that the object represents
(or that is stored with the object) that the interpreter uses to
compute the value of a new object when you use the object in an
expression. For number objects, the number value. For collection
objects, the objects collected. For functions, the signature and
function performed when called.
How is that?
I am starting with the idea that "value" is what we call whatever it is
that is the difference between, for example, the objects int(3) and
int(4). While your definition seems to be saying something similar it
does not seem very precise.
I think necessarily so, or rather, it can only be specific for each
class. In the formulation: an object has identify, class, and value,
class and value are separated. Others have said that type/class is a
universe of possible values and operations on those values. Each
instance has a particular value. 'Universe of possible values' is vague
until one gets specific. For some classes, the possible values are
rather complex.
I prefer another definition of object: an object *is* a value, rather
than *has* a value. That value consists of identity, type (or class), and
everything else of interest which is sometimes also called "value". Since
identity is usually unimportant, and type is assumed from context, we can
often get away with stating that the "everything else of interest" is
*the* value.
I usually talk about one of the three levels of value:
(1) The value of the NAME (or variable) x is the object int(3); that is,
the thing denoted by the symbol x is the object int(3).
(2) The value of the OBJECT int(3) is the specific concrete instantiation
that makes it the thing that it is rather than another thing (a
complicated way of saying that the value of an object is itself); that
is, the thing denoted by the symbol int(3) is some specific byte pattern
in memory which causes that object to be int(3) rather than some other
object.
To put it another way, the value of that object is whatever properties of
the object distinguish it from any other the whole number 1. Since
identity is (usually) unimportant for distinguishing one object from
another (we usually care whether x==y, not whether x is y) the identity
is not part of the value. We're generally indifferent to the serial
number on our ten dollar bills: any note is (usually) as good as any
other note. But sometimes identity is important, and in some specific
contexts I'd be happy to say that the value of a symbol must include the
identity of the object.
(3) But at another level, the value of the object int(3) is the abstract
integer three. This is the only level at which I'm happy to talk about
objects (as opposed to names) "having" a value: "object int(3) has the
value three".
>How would I use your definition to answer the following questions?
* How does an object get a value?
A Python interpreter, human or electronic, creates objects with values
as directed by Python code. How it does so is its private secret ;-).
The directive code includes literals, expressions, and some statements.
I would answer that the object *is* the value, but with the proviso that
we usually don't care about identity:
>>x = 19990
y = 19990
x == y
True
>>x is y
False
I'm happy to say that the value of x and the value of y are the same,
even though they have different identities. But context is important:
there are times were I would want to wrap identity under the umbrella of
value. See below.
>* Can I create an object that has a value that
is the same as int(3) without somehow using an int(3) object in its
construction?
Yes: 1 + 2
Yes: mpz(3) where mpz is multi-precision int class with same set of
possible values as Python ints.
??? 3.0
??? Fraction(3,1)
While Python sees these as *equal*, one could say they are not the same
because they indicate members of different (non-isomorphic) universes.
Whether we wish to say that mpz(3) has the same value as int(3) depends
on what we care about, and we only care about that because our data types
are leaky abstractions. In principle, we should be indifferent to whether
x is int(3), float(3.0), mpz(3), or any other instantiation of the
abstract numeral three. In practice, we're not indifferent: we prefer
ints for mpz objects for some purposes, but not for others. If we care
about the specifics, then we might say they have different values
(because they have different types, and therefore different
characteristics). If we care only about the thing they represent, the
abstract number three, then we'd say that they have the same value.
>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes. Still, numbers,
characters, and collections thereof of what code is usually about.
I would say that all objects *are* values, rather than *have* values. The
value of None is the object None, which is a concrete instantiation of a
selected subset of behaviour of the null object pattern.
>* What is the value of object()?
Essentially none, other than bool(object()) == True. Ditto for None,
other than bool(None) == False. Otherwise, None and object convey no
information.
I would say that the "everything of interest" I referred to above is the
empty set: object() has little or no state. But of course having no state
is itself a state, in the same way that 0 is a perfectly good integer.
In practice, I'd say that object() is one of those cases where we should
include identity in the value. Although we're indifferent as to *which*
object() instance we get, once we've got one, we care whether other
instances are the same instance or different ones. Imagine that object()
keeps a cache of instances, and returns one instead of creating a brand
new object. We don't care which instance we get, or even whether it comes
from the cache or is created fresh. But once we have one, we care about
the identities of others:
special = object() # we don't care which object instance we get
if special is some_other_instance():
print "Match!"
>* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class. In those cases in which the class
of an object can be and is changed to another class, the interpretation
of the value/info of the instance could change and one might claim that
the effective value and hence the value of the object has changed and
hence the answer could be Yes. But this is extremely rarely done and I
could claim that this is a shortcut for creating a new object and
deleting the old.
I would say that the answer to this is, "Would you like to include
behaviour in value?". Let me give you an example:
class String(string):
def upper(self):
return "spam"
s1 = "Norwegian Blue"
s2 = String("Norwegian Blue")
Do s1 and s2 have the same value?
Using definition (1) above, we can see that the names s1 and s2 refer to
different objects, so the names have different values.
Using definition (2), the objects s1 and s2 have different concrete
expressions, and so they are different values. (Remember: the object is
the value.) But from definition (3) they both represent that same
abstract string, so if I care only about that level of description, I'd
say yes they *have* the same value but *are* different values.
Assuming I cared about the behaviour of upper(), then s2 is probably not
suitable for my purposes and so I would like to distinguish s1 from s2.
I'd insist that they have different values which merely looked the same
under equality. To use the bank note analogy, then s1 is legal tender but
s2 is just a very good forgery.
But note that to a collector of forgeries, s2 might be more valuable than
s1, and presumably the writer of class String had a reason for the
behaviour given. The answer to the question "do s1 and s2 have different
values" will depend on why you are asking.
[snip]
>Or perhaps value is some sort of useful but fundamentally undefinable
concept
Either yes or defined in terms of information or universes.
>that disappears when looked at too closely
No.
I would say that although value is dependent on context, that's no excuse
for concluding that it has no meaning. If you look too closely at
*anything*, it becomes fuzzy. (Well, with the possible exception of pure
mathematics.)
--
Steven
On Nov 15, 12:51*am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:
snip
I would say that the answer to this is, "Would you like to include
behaviour in value?". Let me give you an example:
class String(string):
* * def upper(self):
* * * * return "spam"
s1 = "Norwegian Blue"
s2 = String("Norwegian Blue")
Do s1 and s2 have the same value?
Using definition (1) above, we can see that the names s1 and s2 refer to
different objects, so the names have different values.
Using definition (2), the objects s1 and s2 have different concrete
expressions, and so they are different values. (Remember: the object is
the value.) But from definition (3) they both represent that same
abstract string, so if I care only about that level of description, I'd
say yes they *have* the same value but *are* different values.
Assuming I cared about the behaviour of upper(), then s2 is probably not
suitable for my purposes and so I would like to distinguish s1 from s2.
I'd insist that they have different values which merely looked the same
under equality. To use the bank note analogy, then s1 is legal tender but
s2 is just a very good forgery.
But note that to a collector of forgeries, s2 might be more valuable than
s1, and presumably the writer of class String had a reason for the
behaviour given. The answer to the question "do s1 and s2 have different
values" will depend on why you are asking.
snip
I would say that although value is dependent on context, that's no excuse
for concluding that it has no meaning. If you look too closely at
*anything*, it becomes fuzzy. (Well, with the possible exception of pure
mathematics.)
--
Steven
I'm reading that the result of the __eq__ comparison isn't the only
meaning of value, and that there is more than one.
>>class String(str):
.... def upper(self):
.... return "spam"
....
>>s1 = "Norwegian Blue"
s2 = String("Norwegian Blue")
s1== s2
True
>>s1.upper()== s2.upper()
False
Murmur, good. I could see rejecting that two objects of different
types can have the same value. I could also see rejecting that 'the
value than an object is' is nonsense, permitting only 'the value that
an object has'. However, as a counterexample, 'x has the value [1, 2,
3]' and 'x is [1, 2, 3]' are both colloquially sensical statements,
though the latter is imprecise, because 'x is [1, 2, 3], y is [1, 2,
3], x is not y'; certainly '[1, 2, 3]' is neither 'x' nor 'y', and
identity is a commutative relation.
If you'll permit a tangent into another (computer) language, I don't
have a problem saying either that the value of x in 'int* x' in C is a
memory address, or that its value is an integer, which stance is
definitely prone to miscommunication. I still maintain that passing
an object by value calls its copy constructor. ru***@yahoo.com writes:
I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.
I don't remember how the expression 'object value' is used in the Python
docs (and python.org is unreachable from where I am at the moment) but I
know that I don't need such a concept to understand, or code in, Python.
Objects have a type, may have attributes, and that's it!
--
Arnaud
On Nov 14, 8:56 pm, Terry Reedy <tjre...@udel.eduwrote:
ru***@yahoo.com wrote:
>On Nov 13, 4:53 pm, Terry Reedy wrote:
>>ru***@yahoo.com wrote:
I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.
I noticed too. My try:
The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression. For
number objects, the number value. For collection objects, the objects
collected. For functions, the signature and function performed when called.
How is that?
I am starting with the idea that "value" is what we call
whatever it is that is the difference between, for example,
the objects int(3) and int(4). While your definition
seems to be saying something similar it does not seem
very precise.
First of all, thanks. Thanks to your answers I have
finally been able to formulate a concept of Python
values. Now we'll see if it is valid/usable... :-)
I think necessarily so, or rather, it can only be specific for each
class. In the formulation: an object has identify, class, and value,
class and value are separated. Others have said that type/class is a
universe of possible values and operations on those values. Each
instance has a particular value. 'Universe of possible values' is vague
until one gets specific. For some classes, the possible values are
rather complex.
>How would I use your definition to answer the following
questions?
* How does an object get a value?
A Python interpreter, human or electronic, creates objects with values
as directed by Python code. How it does so is its private secret ;-).
The directive code includes literals, expressions, and some statements.
OK.
>* Can I create an object that has a value that
is the same as int(3) without somehow using an
int(3) object in its construction?
Yes: 1 + 2
OK, but my question was too strict.
"1 + 2" is shorthand for: int(1).__add__(int(2))
Rephrasing: is possible to create an object that has
a value that is the same as int(3) without somehow
using a method of the int class (or sub/super-class)
in its construction?
I think it is not possible in the Python language.
That is one could in theory have a float method,
to_int(), but it could not be implemented in the
Python language (as opposed to implemented in the
Python implementation) without using int(), or some
other callable that uses int().
Yes: mpz(3) where mpz is multi-precision int class with same set of
possible values as Python ints.
The argument to mpz() is int(3).
??? 3.0
??? Fraction(3,1)
While Python sees these as *equal*, one could say they are not the same
because they indicate members of different (non-isomorphic) universes.
At this point, I would so say.
>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value"
and not having a value.
Still, numbers, characters, and collections thereof of what code is
usually about.
Yes, which is why we have int, str, and list classes
which, unlike some others, can have values.
>* What is the value of object()?
Essentially none, other than bool(object()) == True.
Ditto for None, other than bool(None) == False.
Otherwise, None and object convey no information.
A method/function can use whatever characteristic of
its arguments that it wants. For example, id() pays no
attention to the value of its argument, only its identity.
So we can say that the bool class constructor returns
True for all object except None. Since None is a
singleton, bool() can identify it by identity, without
consideration of it's (non-existent I propose) value.
>* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class.
The value of a class is it's attributes?
Are you saying that attributes of an object are
part of its value? That would mean that 'a'
and b' below have different values?
class My_int(int):
def __init__(self): self.foo = None
a = int(3)
b = My_int(3)
I propose that attributes are not part of a class'
(or any other object's) value and that a class object
has no value.
of an object can be and is changed to another class, the interpretation
of the value/info of the instance could change and one might claim that
the effective value and hence the value of the object has changed and
hence the answer could be Yes. But this is extremely rarely done and I
could claim that this is a shortcut for creating a new object and
deleting the old.
>* If two objects have different unrelated types
(i.e. not subclassed), are their values necessarily
different (regardless of how they print, or act
when used in an expression)?
No. See above Q. about int(3).
I now think this answer is yes. See above Q. about int(3). :-)
>* What if they aren't unrelated but one is a sub-
class of the other?
Easier no than above.
Yes, I agree no. :-)
>* Can one completely hide an object's value by
overriding methods?
You tell me ;-)
My guess is no. For example, if I try to make int that
appears to be 1 + its "real" value:
class myInt (int):
def __repr__ (self): return int.__repr__(self + 0)
def __str__ (self): return int.__str__(self + 0)
def __add__ (self, x): return int.__add__(self, x + 1)
def __radd__ (self, x): return int.__add__(self, x + 1)
def __sub__ (self, x): return int.__sub__(self, x - 1)
def __rsub__ (self, x): return int.__sub__(self, x - 1)
...etc...
At first it seems to work:
>>a = myInt(3)
a
4
>>a + 3
7
>>2 - a
-2
But
>>5.0 + a
8.0
:-(
Do you have an example that you were thinking of?
Nothing specific. I was trying to see if one can
separate the behavior of objects from whatever it
is that constitutes value. The example above conveys
to me at least that value and behavior *can* be
separated -- even if one could completely hide the
"real" value of an object, one can still view it
as having a real value, and it's apparent value as
something produced by it's behavior.
>* Can two objects have the same value, even if the
methods of one have been overridden to hide it's
value as completely as possible?
I wonder if all values come, directly or indirectly,
from "valued objects" created in the C-API?
CPython creates objects with values in C functions. I presume most are
exposed in the API. But my definition is intentionally not specific to
any implementation.
OK, s/C-API/implementation/
>Or perhaps value is some sort of useful but fundamentally
undefinable concept
Either yes or defined in terms of information or universes.
>that disappears when looked at too closely
No.
Good, I am not chasing a chimera.
>Leaving behind only state and behavior?
State is a choice amoung possible states, which is to say, information.
Behavior is determined by class,
Here is my (tentative) concept of value. I will
give a wordy version and leave a clear, concise
definition to later, or someone else, whichever
occurs first. :-)
Some builtin[1] objects have a value.
A value is a "hidden" piece of data in an object
that is not directly accessible from the Python
language; access to an object's value is provided
only through methods of the object's class. The
object's methods can (and usually will) make use
of the object's value when producing an object
to return or changing the object's state or value.
It is not possible to define a class in Python
that provides its objects with a value unless
that class is derived from a builtin class that
provides a value.[3]
If this in not an inaccurate description of "value"
it clears up several points of confusion for me:
* No need to worry about what the value of object() is.
(it has no value.)
* No need to worry about whether expressions return
values. (They don't, they always return (references
to) objects.)
* Where do values come from? (They are created/modified
by methods of builtin classes and are otherwise not
directly accessible.)
* How can I find an object's value (if I don't believe
.str(), .repr(), etc)? Use gdb. :-)
Notes:
[1] "builtin" is not the right word, but I'm not sure
what is. I mean, in C-Python, an object created
using the C-API, rather than purely in Python. This
includes true builtin objects, as well as objects
created in C extensions in stdlib and 3rd-party
extensions. How to express the distinction
between classes that are or can be defined purely
in Python and those that aren't (can't), in an
implementation independent way, I don't know.
(I presume that in PyPy, everything is defined
in Python.)
[2] I wrote things like "... is not directly accessible"
and "is not possible to...". That is true for C-Python
but other implementations could violate those statements.
So they probably should be rewritten to "... need not
be directly accessible", "need not be possible to...",
etc.
[3] For rhetorical purposes I am writing factually. In
reality I am not certain of most of what I've written.
I'm sure mistakes will not go uncorrected and view
this thread as a learning exercise. ru***@yahoo.com wrote:
On Nov 14, 8:56 pm, Terry Reedy <tjre...@udel.eduwrote:
First of all, thanks. Thanks to your answers I have
finally been able to formulate a concept of Python
values. Now we'll see if it is valid/usable... :-)
Good questions help refine a concept.
>>* Can I create an object that has a value that
is the same as int(3) without somehow using an
int(3) object in its construction?
Yes: 1 + 2
OK, but my question was too strict.
"1 + 2" is shorthand for: int(1).__add__(int(2))
Both are shorthand for int.__add__(int(1),int(2)). Liskov intentionally
designed CLU with methods belonging to classes, not instances, because
the binary op case does not fit the idea of some that a method is a
message to an actor, that 1+2 means 'hey 1, add 2 to yourself'.
....
>>* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class.
The value of a class is it's attributes?
Are you saying that attributes of an object are
part of its value?
Either: objects have 4 aspects -- id, class, attributes, and value
Or: attributes are included with value, so that obs have 3 aspects --
id, class, and value.
[Or: (Aprano) id, class, and attributes are included with value.]
I an not sure yet which viewpoint/formulation is the more useful. I
answered from the 3-aspect viewpoint. It is more traditional, but
probably predates 'objects with attributes' as opposed to 'strucures
with fields'. But I suspect that the values of the fields would be
considered the value of the structure. In any case, I have also
considered the 4-aspect view also.
That would mean that 'a'
and b' below have different values?
class My_int(int):
def __init__(self): self.foo = None
a = int(3)
b = My_int(3)
Yes, and indeed, a.foo raises an exception and b.foo does not.
If attributes are included with value, then value must be subdivided
into attributes and private value. For numbers, the private value is
the numerical value; it cannot be accessed separate from the number
object itself. Strings have a private value which can be exposed a
character or slice at a time. Numbers and strings are the two classes
with literals.
I propose that attributes are not part of a class'
(or any other object's) value and that a class object
has no value.
That is the first choice of the either/or choice above. It is okay as
long as it is understood that 'value' is being used in a restrictive sense.
Here is one reason I have not adopted it yet (and I need to make a
choice for the algorithm book I am writing). Consider a(b). This means
'call a with argument b'. I would rather say 'the value of a is what it
does with b (for all possible b), which is to say, the mapping it
implements', than to explain calling in terms of an
implementation-dependent, essentially private, attribute structure.
So I am thinking I may go with
class: determines universe of possible values of instances and (with
superclasses) functions such instances can work with. 'Functions'
includes all types of syntactic expressions.
value: determine specific result when used as argument in functions
Terry Jan Reedy
On Nov 15, 4:12 pm, Terry Reedy <tjre...@udel.eduwrote:
ru***@yahoo.com wrote:
>On Nov 14, 8:56 pm, Terry Reedy <tjre...@udel.eduwrote:
....snip...
>>>* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class.
So if method .foo() is an instance attribute it
is part of the object's value, but if it is part
of the object's class, it is part of the object's
behavior? Even though calling obj.foo() causes
exactly same results? I can see that a case can
be made for defining things that way, but it doesn't
seem desirable.
>The value of a class is it's attributes?
Are you saying that attributes of an object are
part of its value?
Either: objects have 4 aspects -- id, class, attributes, and value
Or: attributes are included with value, so that obs have 3 aspects --
id, class, and value.
[Or: (Aprano) id, class, and attributes are included with value.]
Or: object attributes are considered together with class
attributes to define an object's behavior leading to:
obs have 3 aspects -- id, behavior, and value.
(The definition of "type" might be stretched a little to
make it synonymous with behavior.)
I an not sure yet which viewpoint/formulation is the more useful. I
answered from the 3-aspect viewpoint. It is more traditional, but
probably predates 'objects with attributes' as opposed to 'strucures
with fields'. But I suspect that the values of the fields would be
considered the value of the structure. In any case, I have also
considered the 4-aspect view also.
>That would mean that 'a'
and b' below have different values?
class My_int(int):
def __init__(self): self.foo = None
a = int(3)
b = My_int(3)
Yes, and indeed, a.foo raises an exception and b.foo does not.
But raising an exception is a aspect of behavior,
not of value.
If attributes are included with value, then value must be subdivided
into attributes and private value. For numbers, the private value is
the numerical value; it cannot be accessed separate from the number
object itself. Strings have a private value which can be exposed a
character or slice at a time. Numbers and strings are the two classes
with literals.
It seems to me that what I think of as "value" is
indeed a sort of private attribute (that's how I
am trying out thinking of it.) But it is its
privateness, its totally different way of getting
created, used, and changed, that is the very thing
that makes it unique and worthy of getting it's
own name.
>I propose that attributes are not part of a class'
(or any other object's) value and that a class object
has no value.
That is the first choice of the either/or choice above. It is okay as
long as it is understood that 'value' is being used in a restrictive sense.
Which seems to me to most closely match the intuitive
sense of value. To me it is intuitive that int(3)
and subclass_of_int(3) have the same value, 3. To
learn that their values are different because one
has an attribute the other didn't, or because the
values in a common (in name) attribute were different,
would be very surprising to me.
Here is one reason I have not adopted it yet (and I need to make a
choice for the algorithm book I am writing). Consider a(b). This means
'call a with argument b'. I would rather say 'the value of a is what it
does with b (for all possible b), which is to say, the mapping it
implements', than to explain calling in terms of an
implementation-dependent, essentially private, attribute structure.
I can see viewing functions in general as a mapping
of arguments values to results in the context of describing
algorithms. I am not sure it is the best way to view
them in the context of how objects are manipulated in
the Python runtime environment.
So I am thinking I may go with
class: determines universe of possible values of instances and (with
superclasses) functions such instances can work with.
If attributes are part of an object's value, that
universe is effectively infinite, isn't it? For
the vast majority of objects (those created in
Python from a class not designed to impose bondage
and discipline by using slots for example) I can
add any attributes I wish with any values I wish
to an object. So class doesn't really determine
much under that definition, does it?
'Functions'
includes all types of syntactic expressions.
Doesn't that use of the word "function" conflict
with the already established use of "function"
in Python. I.e., I think of functions as just
another object, albeit one with a code attribute
that the Python VM knows how to call.
I think of evaluation of expressions as a series
of method (or other callable) executions, each
returning an object that is used in the next step
of the series.
value: determine specific result when used as argument in functions
You are prepared to redefine everything about
objects. I was trying to restrict my redefinition
to only value. But I see your point that the
existing definition of object does not handle
instance attributes very well either.
In comparing your definitions with mine, I think
I see a difference in view point. It seems to me
you give greater attention to class, whereas my
mental model of Python focuses more on individual
objects. I think I was led to that view by Python's
very dynamic behavior. One can dynamically coerse
an A instance into behaving nearly indistinguishably
from a B instance. So what A was before seems some-
what academic.
I tend to think of an object's class as a template
for creating new instances and a convenient place
to stash common attributes to avoid duplicating them
in each instance. (Is this too simplistic?) So I
think of behavior (as defined by attributes) to be
more closely related to the instance than the class.
In my model, there is not a big problem not making
a strong distinction between class attributes and
an instance's attributes -- I think of the union of
the object's attributes, its class' attributes (and
superclass attributes recursively) as all being virtually
part of the instance.
Python itself encourages this view I think. A while
ago I tried to write an object examiner and found it
hard to figure out, in the results for inspect.getmembers(obj),
which belonged to obj, which obj's class, obj's class'
superclass, etc. Same with dir()'s results.
[Tried multiple times to post this but Google errors
out so will try posting in two parts... this is part 2]
On Nov 14, 11:51 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:
>ru***@yahoo.com wrote:
>>On Nov 13, 4:53 pm, Terry Reedy wrote:
ru***@yahoo.com wrote:
>>* Can I create an object that has a value that
is the same as int(3) without somehow using an int(3) object in its
construction?
Yes: 1 + 2
Yes: mpz(3) where mpz is multi-precision int class with same set of
possible values as Python ints.
??? 3.0
??? Fraction(3,1)
While Python sees these as *equal*, one could say they are not the same
because they indicate members of different (non-isomorphic) universes.
Whether we wish to say that mpz(3) has the same value as int(3) depends
on what we care about, and we only care about that because our data types
are leaky abstractions. In principle, we should be indifferent to whether
x is int(3), float(3.0), mpz(3), or any other instantiation of the
abstract numeral three. In practice, we're not indifferent: we prefer
ints for mpz objects for some purposes, but not for others. If we care
about the specifics, then we might say they have different values
(because they have different types, and therefore different
characteristics). If we care only about the thing they represent, the
abstract number three, then we'd say that they have the same value.
You are saying there is no objective definition
of "value". I disagree. I think one can define
value in a useful way that is precise, objective,
and useful.
>>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes. Still, numbers,
characters, and collections thereof of what code is usually about.
I would say that all objects *are* values, rather than *have* values. The
value of None is the object None, which is a concrete instantiation of a
selected subset of behaviour of the null object pattern.
>>* What is the value of object()?
Essentially none, other than bool(object()) == True. Ditto for None,
other than bool(None) == False. Otherwise, None and object convey no
information.
I would say that the "everything of interest" I referred to above is the
empty set: object() has little or no state. But of course having no state
is itself a state, in the same way that 0 is a perfectly good integer.
"interest" is pretty subjective, isn't it? In the
My_int example above, is the .foo attribute of interest
or not? How would I decide? How would you decide?
I was also going to ask about changing methods, but I
see you consider that below.
In practice, I'd say that object() is one of those cases where we should
include identity in the value. Although we're indifferent as to *which*
object() instance we get, once we've got one, we care whether other
instances are the same instance or different ones. Imagine that object()
keeps a cache of instances, and returns one instead of creating a brand
new object. We don't care which instance we get, or even whether it comes
from the cache or is created fresh. But once we have one, we care about
the identities of others:
special = object() # we don't care which object instance we get
if special is some_other_instance():
print "Match!"
>>* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class. In those cases in which the class
of an object can be and is changed to another class, the interpretation
of the value/info of the instance could change and one might claim that
the effective value and hence the value of the object has changed and
hence the answer could be Yes. But this is extremely rarely done and I
could claim that this is a shortcut for creating a new object and
deleting the old.
I would say that the answer to this is, "Would you like to include
behaviour in value?". Let me give you an example:
class String(string):
def upper(self):
return "spam"
s1 = "Norwegian Blue"
s2 = String("Norwegian Blue")
Do s1 and s2 have the same value?
Using my definition of value, the answer is
an unambiguous yes.
Using definition (1) above, we can see that the names s1 and s2 refer to
different objects, so the names have different values.
No, they refer to different objects. The object
str("Norwegian Blue") has a value, tucked away
inside it somewhere, of some implementation defined
bits that encode "Norwegian Blue".
String("Norwegian Blue") is a subclass of str
and has the same value. (Actually, we don't really
care about bit patterns, it is enough to declare
that the values stored in the objects are the same
because that's how the language is defined.)
If they appear different when .upper() is called,
it is because the two types (i.e. behaviors) are
different.
Using definition (2), the objects s1 and s2 have different concrete
expressions, and so they are different values. (Remember: the object is
the value.)
Sorry, I disagree.
But from definition (3) they both represent that same
abstract string, so if I care only about that level of description, I'd
say yes they *have* the same value but *are* different values.
They "have" the same value, it is the difference
in their behavior (type) that produces different
results from .upper().
class xint (int):
def bigger(self):
"return a number bigger than me."
return self + 2
class yint (xint):
def bigger(self):
"return a number very much bigger than me."
return self + 1000
a = xint(5)
b = yint(5)
Do you claim that a and b really have different values?
Assuming I cared about the behaviour of upper(), then s2 is probably not
suitable for my purposes and so I would like to distinguish s1 from s2.
I'd insist that they have different values which merely looked the same
under equality. To use the bank note analogy, then s1 is legal tender but
s2 is just a very good forgery.
But note that to a collector of forgeries, s2 might be more valuable than
s1, and presumably the writer of class String had a reason for the
behaviour given. The answer to the question "do s1 and s2 have different
values" will depend on why you are asking.
That is ok if one is happy with such a squishy,
subjective definition of value. But I propose
that one can define value in a precise way that
captures what most people think of as value, and
avoids confusing objects (or references to them)
and the value of objects.
Given that "value" is one of the three defining
characteristics of objects, a (the?) central concept
of Python, I don't see how such a subjective definition
as yours is workable.
[snip]
>>Or perhaps value is some sort of useful but fundamentally undefinable
concept
Either yes or defined in terms of information or universes.
>>that disappears when looked at too closely
No.
I would say that although value is dependent on context, that's no excuse
for concluding that it has no meaning. If you look too closely at
*anything*, it becomes fuzzy. (Well, with the possible exception of pure
mathematics.)
But it is desirable to define with as little
fuzz as possible :-)
On Sat, 15 Nov 2008 11:17:07 -0800, rurpy wrote:
>>* Can I create an object that has a value that
is the same as int(3) without somehow using an int(3) object in its
construction?
[...]
>Yes: mpz(3) where mpz is multi-precision int class with same set of
possible values as Python ints.
The argument to mpz() is int(3).
Does mpz take string arguments? If it doesn't, it is easy to imagine a
version that does.
mpz("3")
>>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value" and not having a value.
Ah, the Medieval concept of numbers. Of course it's very much older than
Medieval. Roman and Greek mathematics was bedeviled by their philosophy
that one is the smallest number. (In fact, some early mathematicians
argued that *two* was the smallest number, for the reason that if you
have only one sheep (say) it would be unnatural to say that "I have a
number of sheep") It wasn't until the fifth century C.E. that Indian
mathematicians invented the concept of zero, and it took many centuries
for the idea to get to Europe via the Arabs.
If you wish to say that null values aren't values at all, you will find
that you have many conceptual difficulties. Given:
x = 5
y = 5
z = x - y
you will be forced to say that x and y have values but z does not. But
that doesn't mean that z is undefined -- it means that z is defined and
has no value, which makes communication very much more complicated. You
are forced to say things like:
"The value of the object is the number of sheep in the paddock, unless
the number of sheep is zero, in which case the object has no value..."
which is needlessly complicated.
I say that 0 is a perfectly fine value. So is None, [], {}, and any other
null-value. I recommend you don't complicate and confuse matters by
trying to treat them differently.
>Still, numbers, characters, and collections thereof of what code is
usually about.
Yes, which is why we have int, str, and list classes which, unlike some
others, can have values.
What classes do you think have no values?
[snip]
>>* Does an object's behavior (methods) affect
its value?
My first answer is No. Instance methods are attributes of a class and,
in most cases, the value of a class.
The value of a class is it's attributes? Are you saying that attributes
of an object are part of its value? That would mean that 'a' and b'
below have different values?
class My_int(int):
def __init__(self): self.foo = None
That won't work you know.
a = int(3)
b = My_int(3)
That depends on whether the existence of foo makes a difference to you or
not. Consider pickle. Since pickle can't predict what aspects of the
object are important, it must treat *everything* as significant, and
pickle will absolutely treat a and b as having different values.
(Actually, that's not quite true: by necessity pickle *cannot* treat
identity as important. If your application requires object identity to be
persistent over execution session, you can't do so in Python. Hence
pickle and related serialisers can afford to ignore identity.)
Given input of b, the round-trip of pickle/unpickle must return an object
with a foo attribute. If the round-trip merely returns a My_int instance
without the foo attribute, we would rightly consider it a bug, that the
output doesn't have the same value as the input. Likewise if it returned
int(3) instead of My_int(3).
But other functions may have weaker constraints. Consider sum([a, b]).
The function sum makes no promises that it will return the same type as
it's arguments. Since, *for the purposes of addition*, the foo attribute
has no significance, sum() makes no promise whether the sum of a and b
will include the foo attribute. In fact it does not. As far as addition
is concerned, a and b have the same value, and the foo attribute is lost.
In general, Python makes the fewest possible promises of that nature. If
you want to treat foo as having a significant part of the value of b,
then you need to deal with it yourself, perhaps by writing __add__ and
__radd__ methods to My_int.
But from a philosophical position, as opposed to a practical one, of
course a and b have different values. The value of a is (the integer 3),
and the value of b is (the integer 3 together with an attribute foo),
even if foo is a mere decoration, a stripe of red paint on an otherwise
identical object. Since they are different, the objects a and b have
different values. This is a valid philosophical position, although in
practice we often lower our expectations, especially when duck-typing. We
don't care about the red stripe or not, and so we are indifferent to
whether we get int(3) or My_int(3).
I propose that attributes are not part of a class' (or any other
object's) value and that a class object has no value.
Consider:
import urllib2
x = urllib2.urlopen('http://www.yahoo.com')
y = urllib2.urlopen('ftp://ftp.dina.kvl.dk/pub/Math-reports/README')
Do you really want to say that the objects x and y have the same value
(or worse, "no value") just because all the significant "stuff" that
distinguishes x from y are stored as attributes? I suggest that you are
looking at many conceptual difficulties if you make that distinction.
I would say that the value of the object x is the open HTTP connection to www.yahoo.com while the value of the object y is the open FTP connection
to ftp.dina.kvl.dk/pub/Math-reports/README. The nature of how those
values are stored is irrelevant. Whether they are class attributes in the
Python implementation, or data structures in C, or byte patterns in a
database, is irrelevant (except perhaps for performance issues).
>>* If two objects have different unrelated types
(i.e. not subclassed), are their values necessarily different
(regardless of how they print, or act when used in an expression)?
No. See above Q. about int(3).
I now think this answer is yes. See above Q. about int(3). :-)
>>* What if they aren't unrelated but one is a sub-
class of the other?
Easier no than above.
Yes, I agree no. :-)
Classes and subclasses is a mere implementation detail, a specific method
of implementing a range of useful programming techniques. Consider
delegation as an alternative to inheritance.
class MyInt:
def __init__(self, value):
self.__dict__['_delegate'] = value
def __getattr__(self, name):
return getattr(self._delegate, name)
def __setattr__(self, name, value):
setattr(self._delegate, name, value)
def __delattr__(self, name):
delattr(self._delegate, name, value)
n = MyInt(3)
The object n behaves just like int(3), except the class is different. For
the purposes of arithmetic, why would you insist that their values are
*necessarily* different?
Consider this subclass of int:
class WeirdInt(int):
def __new__(cls, value):
return int.__new__(cls, -value)
def __init__(self, value):
self._magic = value
def __str__(self):
return str(self._magic)
__repr__ = __str__
n = WeirdInt(3)
Why would you say that the value of n is *necessarily* the same as the
value of int(3) just because it is subclassed from int? Let's see how
they behave:
>>3 + 1
4
>>n + 1
-2
>>n
3
I would say that n has a unique value: it is an object that looks like 3
but behaves like -3. It is different from both int(3) and int(-3).
Subclassing is irrelevant.
>>* Can one completely hide an object's value by
overriding methods?
You tell me ;-)
My guess is no. For example, if I try to make int that appears to be 1
+ its "real" value:
[snip failed example]
You neglected to override __float__.
But using the example of WeirdInt above:
>>n + 1.0
-2.0
>Do you have an example that you were thinking of?
Nothing specific. I was trying to see if one can separate the behavior
of objects from whatever it is that constitutes value. The example
above conveys to me at least that value and behavior *can* be separated
-- even if one could completely hide the "real" value of an object, one
can still view it as having a real value, and it's apparent value as
something produced by it's behavior.
Ah, you're coming from the Platonic view of "Ideal Forms". http://en.wikipedia.org/wiki/The_Forms
Aristotle was a critic of that, and I don't think modern philosophers
think too highly of it either. In any case, it's rather impractical to
use as a basis for understanding a programming language.
Here is my (tentative) concept of value. I will give a wordy version
and leave a clear, concise definition to later, or someone else,
whichever occurs first. :-)
Some builtin[1] objects have a value. A value is a "hidden" piece of
data in an object that is not directly accessible from the Python
language; access to an object's value is provided only through methods
of the object's class. The object's methods can (and usually will) make
use of the object's value when producing an object to return or changing
the object's state or value.
I see you are still insisting that value is something that objects "have"
rather than "are". I don't see that this is a useful stance to take,
except in the sense of a comparison to some sort of Platonic Ideal or
abstract concept, e.g. the object int(3) has the value of the abstract
whole number three. That's generally not very helpful: in practice, we
can assume that objects are just like the abstract values, except when
they're not.
(E.g. 1+1 in Python is just like 1+1 in pure mathematics; however
10**10**100 in Python is significantly different from 10**10**100 in pure
maths. For starters, the calculation in Python will probably take longer
than the expected lifespan of the Universe; the calculation in pure maths
takes as long as it takes the mathematician to write down "one
googolplex".)
Working around those leaky abstractions is an important part of
programming, but it doesn't help much trying to understand the principles
of a language.
It is not possible to define a class in Python that provides its objects
with a value unless that class is derived from a builtin class that
provides a value.[3]
Again, I do not believe that this is a helpful approach to take. Why
should the value (or lack thereof) of an object depend on the
implementation details of how it is created?
If this in not an inaccurate description of "value" it clears up several
points of confusion for me:
* No need to worry about what the value of object() is.
(it has no value.)
I don't believe that this is a question that needs any worry. The value
of object() is simply the instance itself.
* No need to worry about whether expressions return
values. (They don't, they always return (references to) objects.)
An expression is a symbol. It's a compound symbol, and potentially large
and complicated, but still a symbol. The term "value" has a perfectly
good definition:
That which a symbol denotes or represents.
Given the expression:
Whatever(57) if y or SomeObject(4, 5, "foo") else SomethingDifferent("x")
we can take the entire expression as a symbolic representation of a
thing. It doesn't matter whether we can determine what that thing is at
compile-time or run-time. We know that at run-time there will be such a
thing, and that thing is the value of the expression. (The sole exception
is if the expression fails to evaluate at all.)
So, if the expression does evaluate, then it has evaluates to a thing. It
represents that thing: when talking or reasoning about the thing, we can
substitute the expression for that thing. Doing so might be counter-
productive, because the expression is so long and complicated. But we can
create a *short* symbol representing the expression, say x, and now talk
about x as a short-hand for the long complicated expression. Going back
to the dictionary meaning of "value", we can say that the value of x is
whatever thing is represented by it, which is the same thing as
represented by the expression, which is whatever object the expression
evaluates to.
In other words: the value of an expression is the object that the
expression evaluates to.
* Where do values come from? (They are created/modified
by methods of builtin classes and are otherwise not directly
accessible.)
There are many things of interest which are not created/modified by
methods of built-in classes, and it would be terribly limiting to say
that they don't have values.
I might choose to implement integers as follows:
class UnaryInt:
def __init__(self, n):
if n == 0:
self.ptr = None
else:
self.ptr = UnaryInt(n-1)
def __add__(self, other):
result = UnaryInt(other)
# Find the end of the linked list.
obj = result
while obj.ptr is not None:
obj = obj.ptr
# And extend it.
obj.ptr = self.ptr
return result
__radd__ = __add__
def __str__(self):
count = 0
obj = self
while obj.ptr is not None:
count += 1
obj = obj.ptr
return "%s" % count
__repr__ = __str__
This is an incomplete class -- I haven't spent the time to implement all
the methods necessary to make it work correctly, so it is *very* easy to
break. For example, don't pass a negative integer to it. I could get that
to work too, but it would require significant effort. But for the simple
case of this demonstration, it is good enough.
According to your definition, UnaryInt(3) has no value. But I argue that
it is merely a different implementation of int(3):
>>n = UnaryInt(3)
n + 4
7
Why should I not say that the value of UnaryInt(3) is three, just like
the value of int(3) is three? The differences are mere implementation
details.
* How can I find an object's value (if I don't believe
.str(), .repr(), etc)? Use gdb. :-)
I would say the object's value is the value, so if you have the object,
you have its value.
What your question really is, how can I be sure that the string
representation of an object tells me everything I want/need to know about
the object? And the answer is, naturally, you can't.
Python has very powerful introspection tools:
type()
str(), repr()
help()
dir()
the inspect module
and probably others. If you want to know what makes a thing (a Python
object) itself instead of another, different, thing, then use them.
--
Steven
On Thu, Nov 13, 2008 at 11:58:18AM -0800, ru***@yahoo.com wrote:
I have yet to see any reasonable definition of a Python value in the
Python docs or elsewhere, despite the fact that a value is one of
the three defining characteristics of an object, a central concept
in Python.
Why does it need to be defined in the Python docs? Is this really
even an important question to answer? Are you unable to write correct
functional programs in Python without having it answered? I suspect
it's not an issue...
Let's assume for the moment that it is, though. The term "value"
already has a meaning... the one ascribed to it by its use in natural
language. One on-line dictionary includes this among its definitions:
magnitude; quantity; number represented by a figure, symbol, or the
like: the value of an angle; the value of x; the value of a sum.
It seems clear that this, or something extremely close to this, is
what is meant in the Python docs by the unqualified use of the term.
So, then, what is the value of a Python object? As has been alluded by
others, it is not possible to formally define or enumerate what such a
value is, in general terms, because the term "object" refers to
to a thing with neither a deterministic nor static identity; in the
abstract an object has no inherent or intrinsic value.
The best you can hope to do is define it in context. To illustrate:
In natural language and the physical world, an object has any number
of values; for example a book has a title, a topic, a weight, a
height, a length, a width, a page count, a word count, a purchase
price, a printing cost, a number of copies sold, a profit per unit
sold, etc. to the limits of your imagination regarding ways to
describe books. Which of these is its "value" depends upon the
context in which you are discussing the book. To the reader, the
value is the price he pays for the book, or perhaps some measure of
the enjoyment he derives from reading it (possibly the amount he would
be willing to pay to buy it). To the seller, the value is perhaps
best represented by the profit per unit sold. To the publisher's
shipper (think FedEx), the value might best be described in terms of
its weight...
Just as in the physical world, in Python an object can be defined such
that it evaluates to different values in different contexts, even
though its state may not have changed between those different
contexts. Therefore the value of an object is dependent upon its data
attributes AND its behaviors defined as methods, as well as the
context in which it is accessed, and is the value to which the object
evaluates in a given expression or context.
If you like, you could think of the value of an object as the set of
all possible values to which the object may evaluate in every possible
context, given a particular state of the object.
--
Derek D. Martin http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFJH9NXdjdlQoHP510RAo5DAJ94IssGt8e1UTv8pNGOac SE54WUpQCfdciX
sMBDjQszo9MTQfd93D5Pavk=
=rdz7
-----END PGP SIGNATURE-----
On Sun, Nov 16, 2008 at 06:06:20AM +0000, Steven D'Aprano wrote:
>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value" and not having a value.
[...]
It wasn't until the fifth century C.E. that Indian mathematicians
invented the concept of zero, and it took many centuries for the
idea to get to Europe via the Arabs.
I think he meant None... Or at least, I personally see a distinction
between zero and None (and so do the Python docs). Zero is a value,
whereas None is specifically intended to denote the lack of any value.
I would, FWIW, only make such a distinction in the context of a
computer program... Clearly in mathematics and elsewhere, zero is the
lack of a value (it is the value of nothingness).
"The value of the object is the number of sheep in the paddock, unless
the number of sheep is zero, in which case the object has no value..."
which is needlessly complicated.
For conversation, yes... but technically correct.
I say that 0 is a perfectly fine value. So is None, [], {}, and any other
null-value. I recommend you don't complicate and confuse matters by
trying to treat them differently.
http://www.python.org/doc/1.5.2/api/noneObject.html
7.1.2 The None Object
PyObject * Py_None
The Python None object, denoting lack of value. This object has no
methods.
The value of a class is it's attributes? Are you saying that attributes
of an object are part of its value? That would mean that 'a' and b'
below have different values?
class My_int(int):
def __init__(self): self.foo = None
That won't work you know.
Perhaps not, but it illustrates the point. This *does* work:
>>class myint(int):
.... def __init__(self, val):
.... int.__init__(val)
.... self.foo = None
....
>>b=myint(3)
b
3
>>b.foo
print b.foo
None
>>a=3
a==b
True
So, your description of value is not consistent with Python's
behavior... Python says the two objects I just created have the same
value. But by your definition, they don't. One of you is wrong... ;-)
That depends on whether the existence of foo makes a difference to you or
not. Consider pickle. Since pickle can't predict what aspects of the
object are important, it must treat *everything* as significant, and
pickle will absolutely treat a and b as having different values.
I don't think that's clear... pickle will treat a and b as having
different *data*... For what it's worth, I think the statement in
the language reference that all objects have a type, an ID, and a
value is quite a poor choice of words. Back in 2000, Frederik Lundh
put it much more accurately, I think: http://effbot.org/zone/python-objects.htm
I think it's up for debate whether the value of attribute of an object
is part of the object's value, if that attribute can never be the
evaluated value of the object itself in an expression -- though only
because it's a semantic argument, and the semantics haven't been
defined. I don't think choosing to say that it is or isn't makes
any practical difference, at all.
But other functions may have weaker constraints. Consider sum([a, b]).
The function sum makes no promises that it will return the same type as
it's arguments. Since, *for the purposes of addition*, the foo attribute
has no significance, sum() makes no promise whether the sum of a and b
will include the foo attribute. In fact it does not. As far as addition
is concerned, a and b have the same value, and the foo attribute is lost.
You seem to be making my point, that the value of an object is
context-specific...
I propose that attributes are not part of a class' (or any other
object's) value and that a class object has no value.
Both of these suggestions are clearly problematical, as when used in
an expression, an object can (and usually does) evaluate to some value
for the purpose of evaluating the expression, and that value may be an
attribute of the class, depending on what we decided is the right
answer to the question above.
I see you are still insisting that value is something that objects
"have" rather than "are".
This falls down, say, for a date object which has the value of the
string representation of the date when printed, and a numeric value
(or some other time object) when used in other expressions, both from
a philisophical and practical standpoint.
Furthermore it falls down semantically; an object has parts that are
not part of its value, and therefore the value and the object can not
be the same. The value is merely one attribute (natural language, not
Python definition) of the object.
[...]
In other words: the value of an expression is the object that the
expression evaluates to.
So too is the value of an object. :)
--
Derek D. Martin http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFJH+QVdjdlQoHP510RAruVAKCrSbpcmKEUsMRHdSyWpD hsLqf1rACgpbaA
BJLW6Tp8ZHy/8Rg701doChg=
=04BU
-----END PGP SIGNATURE-----
On Sun, Nov 16, 2008 at 08:38:25AM +0000, Steven D'Aprano wrote:
I believe that the language reference says that objects have an identity,
a type and state, but I'm too lazy too look it up. I'd be happy with that
definition.
They do indeed say value, not state. As I said in a different
message, I'd agree that it's not a very clear definition.
I don't see how saying "the value of an object is itself" is
particularly useful. We already have a word for what an object is, it
is "object". :-)
I didn't say it was very useful. As far as I'm concerned, asking what the
value of an object is is not a useful question.
Now we agree. :)
The result of x==y depends solely on the behavior (methods) of x.
Nonsense.
It's wrong to say *solely*, but the value of x==y does indeed depend
on the behavior of the methods.
I think the value of x is "a thing which claims to be equal to
everything on Tuesdays, and equal to nothing every other day".
That isn't its *VALUE* -- it's its *IDENTITY*. My weight is not my
identity... but in a certain context, it could be considered my value.
--
Derek D. Martin http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFJH+fddjdlQoHP510RAqP8AJ9DM4KKrTutkXgON66eH7 Bf6FP8sACghak3
z3CqYb8IN9nsxmPYa/5sl3U=
=J2Jc
-----END PGP SIGNATURE-----
Derek Martin <co**@pizzashack.orgwrites:
On Thu, Nov 13, 2008 at 11:58:18AM -0800, ru***@yahoo.com wrote:
>I have yet to see any reasonable definition of a Python value in the
Python docs or elsewhere, despite the fact that a value is one of
the three defining characteristics of an object, a central concept
in Python.
Why does it need to be defined in the Python docs? Is this really
even an important question to answer? Are you unable to write correct
functional programs in Python without having it answered? I suspect
it's not an issue...
Let's assume for the moment that it is, though. The term "value"
already has a meaning... the one ascribed to it by its use in natural
language. One on-line dictionary includes this among its definitions:
magnitude; quantity; number represented by a figure, symbol, or the
like: the value of an angle; the value of x; the value of a sum.
It seems clear that this, or something extremely close to this, is
what is meant in the Python docs by the unqualified use of the term.
I reiterate that IMO the 'value' of an object is not really a useful
concept.
E.g. think of the integer 3. It has a representation ('3'), it compares
to other objects (via int.__eq__, int.__lt__, etc), you can perform
arithmetic operations on it (via int.__add__, int.__sub__, etc), etc.
What more would you want to know about it?
[...]
If you like, you could think of the value of an object as the set of
all possible values to which the object may evaluate in every possible
context, given a particular state of the object.
This definition looks a bit circular to me ;)
--
Arnaud
On Sun, Nov 16, 2008 at 09:30:45AM +0000, Arnaud Delobelle wrote:
[...]
If you like, you could think of the value of an object as the set of
all possible values to which the object may evaluate in every possible
context, given a particular state of the object.
This definition looks a bit circular to me ;)
Why, because it has the word "value" in the definition? It's not
circular. The thing being defined is "value of an object". The word
"value" has a pre-existing well-understood natural language definition.
--
Derek D. Martin http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFJH+rOdjdlQoHP510RAnZQAJ4yeOyjlp+CEbQ/mnARar1nK+IIKACdERYi
blVA42bmuDnDwmcBNcBPMno=
=YY5A
-----END PGP SIGNATURE-----
Derek Martin <co**@pizzashack.orgwrites:
I think he meant None... Or at least, I personally see a distinction
between zero and None (and so do the Python docs). Zero is a value,
whereas None is specifically intended to denote the lack of any value.
None is an 'value' which is intended to denote the absence of any
'value' *other than None*.
I would, FWIW, only make such a distinction in the context of a
computer program... Clearly in mathematics and elsewhere, zero is the
lack of a value (it is the value of nothingness).
I would like to have a word with your maths teacher! There are plenty
of uses for 0, most of which are unrelated to 'nothingess'. E.g. 0 is
*greater* than -1 so it must be something.
--
Arnaud
On Sat, 15 Nov 2008 19:42:33 -0800, rurpy wrote:
You are saying there is no objective definition of "value". I disagree.
I think one can define value in a useful way that is precise,
objective, and useful.
No, I'm not saying that there is no objective definition of value. I'm
saying that the objective definition depends on the circumstances. I
believe that it is foolish to try to avoid context-sensitivity in your
definition of value.
It is possible though. You can consider everything which makes a thing
different from another thing, but taken all the way that leads to
deciding that this sentence:
"The cat sat on the mat."
does not have the same value as this sentence:
"The cat sat on the mat."
because the second one comes further down this document. (I trust that
you understand that sentences are compound symbols, expressions if you
prefer.) I would argue that this is usually a silly distinction, since
the position of a sentence in a document rarely makes a difference to the
meaning (the value) of that sentence. But not always silly. Imagine the
following:
"Harry pointed his massive gun at the fugitive.
'Do you feel lucky?'
[... much later on...]
Working undercover at the casino, Harry adjusted his uniform, brushed a
speck of imaginary dust off the sleeve, and greeted the billionaire.
'Good evening Sir, welcome to the Starlight Casino, your first drink is
on the house. Could I interest you in a game of friendly poker? Do you
feel lucky?'"
Is there any doubt that the same symbol can denote a different meaning (a
value) under different circumstances?
>I would say that the "everything of interest" I referred to above is
the empty set: object() has little or no state. But of course having no
state is itself a state, in the same way that 0 is a perfectly good
integer.
"interest" is pretty subjective, isn't it?
Of course not. If we agree that we want something that undergoes integer
addition as defined by mathematicians, there's nothing subjective about
that. That will immediately rule out vast numbers of values: None, dicts,
lists, strings, and so forth. But it still allows floats, ints, mpz
objects, etc., and in principle we're indifferent to which of them we
get. We may choose to arbitrarily convert objects from one type to
another, whatever is convenient, so long as they can be added together.
Any other property of these types is a red stripe, to be kept if
convenient, discarded if needed, but always ignored.
In the My_int example above,
is the .foo attribute of interest or not? How would I decide?
That depends on what you wish to do with the object. If you just want to
add it to an int, then it is of no interest. It's a red stripe. But if
you want to pass it on to another function which may treat the foo
attribute as significant, then you can't afford to just throw it away. In
other words, you care about the attribute, even if you aren't using it
yourself.
>I would say that the answer to this is, "Would you like to include
behaviour in value?". Let me give you an example:
class String(string):
def upper(self):
return "spam"
s1 = "Norwegian Blue"
s2 = String("Norwegian Blue")
Do s1 and s2 have the same value?
Using my definition of value, the answer is an unambiguous yes.
But that implies that you should be able to use s2 anywhere that you can
use s1, and that's clearly not true:
assert len(s2.upper()) == len(s2)
Since you can't use s1 and s2 in the same places, how can you justify
saying the have the same value?
I have an answer to that: if I don't care about upper(), then I'm happy
to consider them to have the same value. If I do care about the invariant
above, then I can't.
>Using definition (1) above, we can see that the names s1 and s2 refer
to different objects, so the names have different values.
No, they refer to different objects.
"No"? That's what I said.
The object str("Norwegian Blue")
has a value, tucked away inside it somewhere, of some implementation
defined bits that encode "Norwegian Blue".
String("Norwegian Blue") is a subclass of str and has the same value.
Sure, in the specific example I gave, but in general this is not
necessarily the case. Consider this fact: every string can be represented
by a sequence of bytes. A byte can be considered a digit in base 256.
"Norwegian Blue" considered as a number in this fashion is
1590857700756072424900433200051557. With sufficient effort, I could
inherit from long, instead of str, and duplicate the exact behaviour as
str. Subclassing is a red-herring.
(Actually, we don't really care about bit patterns, it is enough to
declare that the values stored in the objects are the same because
that's how the language is defined.) If they appear different when
.upper() is called, it is because the two types (i.e. behaviors) are
different.
But behaviour defines what we interpret the object as. The same bit
pattern represents the number 1590857700756072424900433200051557 and the
string "Norwegian Blue". Without behaviour, how could you tell them apart?
>Using definition (2), the objects s1 and s2 have different concrete
expressions, and so they are different values. (Remember: the object is
the value.)
Sorry, I disagree.
>But from definition (3) they both represent that same abstract string,
so if I care only about that level of description, I'd say yes they
*have* the same value but *are* different values.
They "have" the same value, it is the difference in their behavior
(type) that produces different results from .upper().
class xint (int):
def bigger(self):
"return a number bigger than me."
return self + 2
class yint (xint):
def bigger(self):
"return a number very much bigger than me."
return self + 1000
a = xint(5)
b = yint(5)
Do you claim that a and b really have different values?
That depends on why I'm asking. If all I want is a number that I can add
to 3 and get 8, then I'm indifferent to the choice between a and b and I
would say that their values are not different in any way I care about. If
I want a number than I can add to 3, *and* that returns a number larger
than 1000 when I call the bigger() method, then a will not do but b will
be fine. In this case, I would argue that their values are different.
>Assuming I cared about the behaviour of upper(), then s2 is probably
not suitable for my purposes and so I would like to distinguish s1 from
s2. I'd insist that they have different values which merely looked the
same under equality. To use the bank note analogy, then s1 is legal
tender but s2 is just a very good forgery.
But note that to a collector of forgeries, s2 might be more valuable
than s1, and presumably the writer of class String had a reason for the
behaviour given. The answer to the question "do s1 and s2 have
different values" will depend on why you are asking.
That is ok if one is happy with such a squishy, subjective definition of
value.
There's nothing subjective about it. Two people, given the same
constraints, should be able to agree on whether two objects have the same
value in the context of the problem they are trying to solve.
But I propose that one can define value in a precise way that
captures what most people think of as value, and avoids confusing
objects (or references to them) and the value of objects.
Good luck. I think you're chasing your own shadow.
Given that "value" is one of the three defining characteristics of
objects, a (the?) central concept of Python, I don't see how such a
subjective definition as yours is workable.
You've said that attributes are not part of the value, and thus denied
that the state of an object is the object's value. Given that, I don't
think your definition is workable. I think it's counter-productive to try
to define value in such a way that most Python objects have no value,
especially the most high-level objects.
--
Steven
On Sun, 16 Nov 2008 04:12:53 -0500, Derek Martin wrote:
On Sun, Nov 16, 2008 at 06:06:20AM +0000, Steven D'Aprano wrote:
>>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value" and not having a
value.
[...]
>It wasn't until the fifth century C.E. that Indian mathematicians
invented the concept of zero, and it took many centuries for the idea
to get to Europe via the Arabs.
I think he meant None... Or at least, I personally see a distinction
between zero and None (and so do the Python docs).
Of course zero is different from None. For starters, you can't add 1 to
None.
Zero is a value,
Yes it is.
whereas None is specifically intended to denote the lack of any value.
None is intended to be *interpreted* by the programmer as the lack of any
other value. That's what the null object pattern is. MySql has a Null, C
has null pointers, Pascal has the nil pointer, Python has None, integer
mathematics has 0, matrix mathematics has any number of identity matrices
under addition, the ASCII character set has nul... in some older
programming frameworks, numbers like 9999 or -1 are used. (I remember a
bug in "Arrow Accounting" that occurred because empty integer fields were
set to 99 or similar.)
I
would, FWIW, only make such a distinction in the context of a computer
program... Clearly in mathematics and elsewhere, zero is the lack of a
value (it is the value of nothingness).
Contradicting your claim above, not to mention about five hundred years
of European mathematics and about 1500 years of Indian mathematics.
>"The value of the object is the number of sheep in the paddock, unless
the number of sheep is zero, in which case the object has no value..."
which is needlessly complicated.
For conversation, yes... but technically correct.
No, I would say the value of the object is the number of sheep,
regardless of whether that number is 0 or 1 or 99.
>I say that 0 is a perfectly fine value. So is None, [], {}, and any
other null-value. I recommend you don't complicate and confuse matters
by trying to treat them differently.
http://www.python.org/doc/1.5.2/api/noneObject.html
7.1.2 The None Object
PyObject * Py_None
The Python None object, denoting lack of value. This object has no
methods.
I would argue that this particular doc is badly worded. Because Python
doesn't have uninitialized variables, programmers need a value to stand
in for "I don't have a real value for this yet". By convention, None is
usually that value, although object() is another reasonable choice, for
when None is needed for something else.
The value of a class is it's attributes? Are you saying that
attributes of an object are part of its value? That would mean that
'a' and b' below have different values?
class My_int(int):
def __init__(self): self.foo = None
That won't work you know.
Perhaps not, but it illustrates the point. This *does* work:
>>>class myint(int):
... def __init__(self, val):
... int.__init__(val)
... self.foo = None
...
>>>b=myint(3)
b
3
>>>b.foo
print b.foo
None
>>>a=3
a==b
True
So, your description of value is not consistent with Python's
behavior... Python says the two objects I just created have the same
value. But by your definition, they don't. One of you is wrong... ;-)
No, Python says that the two objects are equal. That's not the same thing.
Unicode strings and byte strings are not the same things:
>>u'3' == '3'
True
Consider also:
>>int(3) == float(3)
True
>>decimal.Decimal(3) == int(3)
True
>>decimal.Decimal(3) == float(3)
False
>That depends on whether the existence of foo makes a difference to you
or not. Consider pickle. Since pickle can't predict what aspects of the
object are important, it must treat *everything* as significant, and
pickle will absolutely treat a and b as having different values.
I don't think that's clear... pickle will treat a and b as having
different *data*...
Define data, and how is it different from value?
For what it's worth, I think the statement in the
language reference that all objects have a type, an ID, and a value is
quite a poor choice of words. Back in 2000, Frederik Lundh put it much
more accurately, I think:
http://effbot.org/zone/python-objects.htm
Yes. For content, you can also say state.
>I see you are still insisting that value is something that objects
"have" rather than "are".
This falls down, say, for a date object which has the value of the
string representation of the date when printed, and a numeric value (or
some other time object) when used in other expressions, both from a
philisophical and practical standpoint.
No, the value of a date object is neither its printable string
representation, nor the implementation-dependent numeric value in seconds.
Furthermore it falls down semantically; an object has parts that are not
part of its value, and therefore the value and the object can not be the
same. The value is merely one attribute (natural language, not Python
definition) of the object.
I don't agree that this necessarily follows. We say that the value of an
symbol is that which the symbol represents. Consider a map, with a little
radioactive symbol representing a nuclear reactor. Note that the same
symbol is used for the 100 megawatt CANDU reactor here, and the 2
megawatt heavy-water research reactor over there: radically different
things but denoted by the same symbol.
If protesters cut down the chainlink fence surrounding the power station,
do we have to gather up all the maps and erase a pixel from the symbol?
How do we identify which pixel represents the fence and which ones
represents the reactor core?
I would answer these questions by saying that for the purposes of the
map, the chainlink fence is unimportant. The size of the reactor is
unimportant. We can use the same symbol for both reactors, despite the
differences, because for the purpose of mapping the only thing that
matters is the nuclear core. we say that, for the purpose of the map, the
two sites have the same value. The fence is like an attribute of the
reactor object, and irrelevant.
But if you're providing security cameras for the site, then the fence is
very important. For that purpose, you can't interpret both reactors the
same. You might have to use a different symbol, say "Reactor 1" and
"Reactor 2", for them, and you would *not* say that Reactor 1 and Reactor
2 have the same value.
--
Steven
Steven D'Aprano wrote:
On Sat, 15 Nov 2008 19:42:33 -0800, rurpy wrote:
[...]
>But I propose that one can define value in a precise way that
captures what most people think of as value, and avoids confusing
objects (or references to them) and the value of objects.
Good luck. I think you're chasing your own shadow.
Quite. The question naturally arises "Why would one want to?" This is
naturally followed by "How would it help if you did?"
Can't we just get back to programming? If this endless (sigh) discussion
actually helped anybody to understand how Python worked I could
sympathize with it.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steven D'Aprano wrote:
On Sat, 15 Nov 2008 19:42:33 -0800, rurpy wrote:
[...]
>But I propose that one can define value in a precise way that
captures what most people think of as value, and avoids confusing
objects (or references to them) and the value of objects.
Good luck. I think you're chasing your own shadow.
Quite. The question naturally arises "Why would one want to?" This is
naturally followed by "How would it help if you did?"
Can't we just get back to programming? If this endless (sigh) discussion
actually helped anybody to understand how Python worked I could
sympathize with it.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steven D'Aprano wrote:
On Sat, 15 Nov 2008 11:17:07 -0800, rurpy wrote:
[...]
>* How can I find an object's value (if I don't believe
.str(), .repr(), etc)? Use gdb. :-)
I would say the object's value is the value, so if you have the object,
you have its value.
[...]
There's also the question, if you say that an object is different from
its value, of determining what the value's value is ...
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steven D'Aprano wrote:
>Because of
Python's interpreted nature, names can't be compiled away as in C, they
need a concrete runtime existence, but does the language definition need
to assume that?
Of course. It wouldn't be Python if they didn't. However, remember that
objects don't have names.
Actually, Python pretty much does compile away names for function
bodies. (They are replaced by array indexes.) It only needs to
manifest them for locals(). CPython Dis.dis also accesses them, but
that is obviously implementation specific. I suspect that the names are
stored as C char sequences rather than as Python string objects unless
and until the latter are needed for locals().
....
>>>class EqualsAll(object):
... def __eq__(self, other):
... return True
...
>>>5 == EqualsAll()
True
The methods of 5 don't even get called.
Why do you say that? As I read the manual, type(left-operand).__eq__ is
called first.
This of course is a special case, because 5 is a built-in,
If true, this would be CPython-specific optimization, not language
definition.
but in general, the result of x==y depends on *both* x and y.
True. But type(x) gets first crack at the answer.
....
You're assuming that == compares values, which is often a safe
assumption, but not always.
The default is to compare by identity, so assuming otherwise is only
safe when one knows the classes of x and y to over-ride the default.
Terry Jan Reedy
On Nov 16, 5:12 pm, Steve Holden <st...@holdenweb.comwrote:
>The Python Reference Manual states that an object
consists of identity, type, and value. "Identity"
seems to be non-controversial.
Let's take "type" as meaning the attributes an
object inherits from it's class. "value" is then
what is left: the object's local attributes and
the intrinsic-value described above.
This seems to be the most common view of "value",
and similar to the one Fredrik Lundh takes in
http://effbot.org/zone/python-objects.htm
which was pointed to in an earlier response
(he calls it "content")
One could also take all attributes accessible
through obj (its class' attributes as well as
its local attributes) as "type" leaving only
intrinsic-value as "value".
This was the view I proposed.
Or one could adopt what Terry Reedy called a
4-aspect view: an object is identity, class,
value (or local-state or something) and
intrinsic-value.
I don't understand Python well enough to defend
any of these descriptions (I now realize, despite
my previous postings to the contrary. :-)
But what I do defend is the concept of intrinsic
value which I have not ever seen explicitly stated
anywhere and which clarifies a lot of things for me.
For example, you can define the value of None
however you want, but it seems clear that it has
(and needs) no intrinsic-value. Same with object().
In that case I am not sure why this happens:
>>>a = object()
b = object()
a == b
False
Who said the equality operator compares values
and that Python guarantees that it will always
return True if the values of its arguments are
the same? You yourself point out below that this
is not true -- one can define "==" any way
one wishes. If you can do so, can't the Python
language developers who implement "==" also do
so? In fact they did do so in this case, they
compare id's.
So the next question is, "why not define value
equality (and implicitly values) to be whatever
"==" says it is"? Well you could I suppose. The
only hard constraints are that it be logically
consistent, and not lead to erroneous conclusions
about how Python works. Soft constraints are that
in be easily understandable, and be intuitive.
I don't know if using "==" would meet the two hard
constraints, but it fails the two soft ones.
The context of the definition of "value" in the
Language Reference is where the basic properties
of objects are being described. Why would one
want to make the definition of objects, the core
concept of Python, dependent on the behavior of
the "==" operator?
Since those objects are of the same type, and since they have no
"intrinsic value", it would seem you'd expect them to be equal. But they
aren't, because (in the absence of an explicit equality test method)
equality is tested for by testing for identity.
I would expect them to be equal, but apparently
Python's designers thought otherwise. :-)
The "==" operator is designed to return results
that make the most sense (where sense is a
complicated function in the brains of the Python
developers.) In calculating that return value,
Python need not return true for the "same"
intrinsic values any more than than an object
you define in Python has to.
>I now understand why the only way to describe the
object int(2) is requires using str/repr whereas
with objects without an intrinsic value, I can
describe without needing str/repr.
I can think of expressions as always returning
objects, never "values".
Etc...
So, is this point of view any more acceptable?
Why not just accept that equality is determined by
the __eq__ method [2]?
I do. But equality is not the same as "same-ness"
[Oh god, here comes another round of philosophical
discussion. :-)]
Python can have objects that
don't equal anything, even themselves, objects that
are equal to everything, and all definitions in between.
So "equality" doesn't necessarily mean that the values
are the same.
Right! Which is exactly why equality is not the
right concept for trying to think about, "what are
the basic aspects of an object?" and "what is the
value of an object?".
If objects have values that differ from the object itself, then aren't
those values themselves objects? If so, what are the values of those
objects?
Yes, the intrinsic value of a list object contains
(references to) other objects. But note that I did
not claim to say *what* an instrinsic value was or
what it's value was, only that:
* it exists (in some but not all objects).
* builtin[*3] methods and functions can access
it and use it to decide what they will return.
* that it is not accessible from Python language
directly, only though the behavior of the those
builtin methods/functions.[*4]
* That however you define "value" in the P.L.R.
sense) it must include intrinsic value (if any)
So however P.L.R. "value" is defined, it must be
recursive (i.e. the value of [1, [2, 3]] is different
than [1, [2, 4]].)
[*3] Again, I do not have a good term for this but
mean code that is part of the implementation: for
C-Python that would be C-API code that can directly
access an object's implementation.
[*4] That should probably be "may not be accessible..."
since I could imagine an implementation like PyPy
representing such "hidden state" using regular Python
objects.
regards
Steve
>[*1] I took note of Terry Reedy's point that
a.__add__(b) is really int.__add__ (a, b) but
since the two descriptions are isomorphic at
the level I am discussing, it seemed clearer
to leave class out of it.
[2] This is a simplification, since the interpreter will fall back on
other methods in the absence of __eq__.
ru***@yahoo.com wrote:
Or one could adopt what Terry Reedy called a
4-aspect view: an object is identity, class,
value (or local-state or something) and
intrinsic-value.
What I specifically said is id, class, instance attributes, and private
data. So objects have only one, some only the other, some both, and
some neither. I also noted that the boundary between properties and
instance methods of the class and attributes of the instance is somewhat
flexible.
I think the important point is this. In Python, objects are
self-identifying bundles of information, which is to say, the bundle
includes knowledge of the which universe of possible bundles the object
comes from, where the universe includes a set of operations. This is
sometimes called RTTI -- run-time type information. This is in contrast
to other languages and signal-processors where information
(bit-patterns) is usually *not* self-identifying, but the universe must
be somehow enforced by a compiler or carried in the context. In C, for
instance, most types cannot have RTTI and RTTI is only required for
unions. Programmers can give structs a type field and that is how
CPython implements PyObjects.
Terry Jan Reedy
"Steve Holden" <st***@ho.omwrote:
There's also the question, if you say that an object is different from
its value, of determining what the value's value is ...
This one is easy - its obviously the value that is returned when the value
is returned when you call for the value that you are interested in, unless
you are interested in the bare value, in which case its the value that is
returned.
I am beginning to suspect that Steven de'A is hammering away at this
to take his mind off the recent cricket game between his country's team
and India. Anything is better than contemplating that. It was enough to
shake one's faith in Southern Supremacy...
:-)
- Hendrik
--
And there was wailing and gnashing of teeth...
"Terry Reedy" <tj*****@udel.eduwrote:
I think the important point is this. In Python, objects are
self-identifying bundles of information, which is to say, the bundle
includes knowledge of the which universe of possible bundles the object
comes from, where the universe includes a set of operations. This is
sometimes called RTTI -- run-time type information. This is in contrast
to other languages and signal-processors where information
(bit-patterns) is usually *not* self-identifying, but the universe must
be somehow enforced by a compiler or carried in the context.
This is an important distinction, and it goes even deeper - in some
low level code, the "organisation" consists solely of a priori knowledge
in the mind of the assembler or C programmer - that is also why it is so
difficult to understand machine code - the individual instructions may
be well defined, but because there is no obvious context, it is hard
to figure out what the original programmer's intentions were.
In C, for
instance, most types cannot have RTTI and RTTI is only required for
unions. Programmers can give structs a type field and that is how
CPython implements PyObjects.
Yes, and for some objects, part of that struct is the piece that is
effectively the "value" field, and the content of that is what the
value is.
And here one is faced with the same problem as I pointed to above -
if you do not have access to the struct definition (which you
don't have at run time), its kind of difficult to figure out where
the value is, and you can only access it via the public methods
supplied, if any.
- Hendrik
On Nov 17, 12:20 pm, "Hendrik van Rooyen" <m...@microcorp.co.za>
wrote:
"Steve Holden" <st***@ho.omwrote:
>There's also the question, if you say that an object is different from
its value, of determining what the value's value is ...
This one is easy - its obviously the value that is returned when the value
is returned when you call for the value that you are interested in, unless
you are interested in the bare value, in which case its the value that is
returned.
Except of course, values are *never* returned,
only objects. This is why the concept of an object's
intrinsic value is important. I now understand
that at some point when chasing values, you will
eventually[*1] encounter an object with no intrinsic
value or one for which you have to rely on repr()
to tell you its value; there is no other way to
examine it from the "outside" since (in C-Python)
its value in in a form only C-level code can
understand.
[*1] Excluding circularly linked chains of values
of course.
* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value"
and not having a value.
I think the difference is concrete... an uninitialized variable in C
has no value, I'd say, because the value it will have is
indeterminate, it will be whatever happens to be sitting at that
location in memory, inconsistent. If that variable is initialized to
some value representing "none", like NULL, then it has a consistent
value of "none". There is no way to have an uninitialized variable in
python, so they are always consistently set, so they always have
values.
?
On Nov 17, 8:35*pm, Craig Allen <callen...@gmail.comwrote:
>* Do all objects have values? (Ignore the Python
>*docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value"
and not having a value.
I think the difference is concrete... an uninitialized variable in C
has no value, I'd say, because the value it will have is
indeterminate, it will be whatever happens to be sitting at that
location in memory, inconsistent. *If that variable is initialized to
some value representing "none", like NULL, then it has a consistent
value of "none". *There is no way to have an uninitialized variable in
python, so they are always consistently set, so they always have
values.
?
If he was dying, he wouldn't have bothered to carve 'Aaaauuuggghhhh'.
He'd just say it.
#269 and counting!
On Sun, 16 Nov 2008 23:34:58 -0500, Terry Reedy wrote:
Steven D'Aprano wrote:
>>>>class EqualsAll(object):
... def __eq__(self, other):
... return True
...
>>>>5 == EqualsAll()
True
The methods of 5 don't even get called.
Why do you say that? As I read the manual, type(left-operand).__eq__ is
called first.
Ah, I could be confabulating that with arithmetic operators __add__ etc.
It may be that comparisons use a different mechanism:
>>5 .__cmp__(EqualsAll())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: int.__cmp__(x,y) requires y to be a 'int', not a 'EqualsAll'
--
Steven
On Mon, 17 Nov 2008 18:35:04 -0800, Craig Allen wrote:
>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value" and not having a value.
I think the difference is concrete... an uninitialized variable in C has
no value, I'd say, because the value it will have is indeterminate, it
will be whatever happens to be sitting at that location in memory,
inconsistent. If that variable is initialized to some value
representing "none", like NULL, then it has a consistent value of
"none". There is no way to have an uninitialized variable in python, so
they are always consistently set, so they always have values.
?
Well said.
I'd even go so far as to say that an uninitialized variable in C has a
random value, unless the compiler prevents you from accessing it. If the
compiler lets you (accidentally, I assume!) do something with an
uninitialized variable, then you're accessing whatever random value it
happens to get.
--
Steven
On Mon, 17 Nov 2008 22:08:04 +0200, Hendrik van Rooyen wrote:
And here one is faced with the same problem as I pointed to above - if
you do not have access to the struct definition (which you don't have at
run time), its kind of difficult to figure out where the value is, and
you can only access it via the public methods supplied, if any.
Asking *where* the value is is a completely different question to asking
*what* the value is.
I demonstrated that earlier in this thread, where I implemented the
beginnings of an int-class using unary notation, using a linked list. The
value of the object was encoded by the length of the chain of objects, so
there was no "where" that value was stored. It was distributed over the
entire linked list.
--
Steven
On 2008-11-12, greg <gr**@cosc.canterbury.ac.nzwrote:
Here is the definition of call-by-value from the
"Revised Report on the Algorithmic Language Algol 60"
<http://www.masswerk.at/algol60/report.htm>:
4.7.3.1. Value assignment (call by value). All formal parameters quoted in the
value part of the procedure declaration heading are assigned the values (cf.
section 2.8. Values and types) of the corresponding actual parameters, these
assignments being considers as being performed explicitly before entering the
procedure body. The effect is as though an additional block embracing the
procedure body were created in which these assignments were made to variables
local to this fictitious block with types as given in the corresponding
specifications (cf. section 5.4.5).
There you have it -- call by value is offially defined in
terms of assignment. There is no mention in there of copying.
Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.
You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.
If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term and it would be better to talk
about call by copy in the case of C, to make sure one understands
the difference between what happens in C and what happens in
other languages that also have "call by assignment" but behave
very differently.
--
Antoon Pardon
On Nov 18, 2:21*am, Antoon Pardon <apar...@forel.vub.ac.bewrote:
On 2008-11-12, greg <g...@cosc.canterbury.ac.nzwrote:
Here is the definition of call-by-value from the
"Revised Report on the Algorithmic Language Algol 60"
<http://www.masswerk.at/algol60/report.htm>:
4.7.3.1. Value assignment (call by value). All formal parameters quotedin the
value part of the procedure declaration heading are assigned the values(cf.
section 2.8. Values and types) of the corresponding actual parameters, these
assignments being considers as being performed explicitly before entering the
procedure body. The effect is as though an additional block embracing the
procedure body were created in which these assignments were made to variables
local to this fictitious block with types as given in the corresponding
specifications (cf. section 5.4.5).
There you have it -- call by value is offially defined in
terms of assignment. There is no mention in there of copying.
Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.
You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.
If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term and it would be better to talk
about call by copy in the case of C, to make sure one understands
the difference between what happens in C and what happens in
other languages that also have "call by assignment" but behave
very differently.
--
Antoon Pardon
I think Joe's argument was, C and Python can both be call-by-value, so
long as Python variables are construed to be pointers. To him,
pointers are easy to understand, even for novices, and the copy
constructor for pointers is trivial.
Otherwise, C and Algol have different definitions of call-by-value,
and while Java might be Algol-call-by-value, Python is not C call-by-
value. So, between C and Algol has majority and which has seniority
claim to the term?
On 2008-11-12, greg <gr**@cosc.canterbury.ac.nzwrote:
Steven D'Aprano wrote:
>Why should anyone take the "Revised Report on the Algorithmic Language
Algol 60" as the "official" (only?) definition of call-by-value for all
languages everywhere?
Since the term was more or less invented by the people
who designed Algol, I thought it would be a good idea to
find out, from as close to the source as possible, what
*they* intended it to mean.
But you didn't try to find out their intention. You just took their
words and applied it in a different context. It isn't at all obvious
that placing their words in a context with different assignment
semantics would preserve their intend.
--
Antoon Pardon
Steven D'Aprano wrote:
On Mon, 17 Nov 2008 18:35:04 -0800, Craig Allen wrote:
>>>>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value" and not having a value.
I think the difference is concrete... an uninitialized variable in C has
no value, I'd say, because the value it will have is indeterminate, it
will be whatever happens to be sitting at that location in memory,
inconsistent. If that variable is initialized to some value
representing "none", like NULL, then it has a consistent value of
"none". There is no way to have an uninitialized variable in python, so
they are always consistently set, so they always have values.
?
Well said.
I'd even go so far as to say that an uninitialized variable in C has a
random value, unless the compiler prevents you from accessing it. If the
compiler lets you (accidentally, I assume!) do something with an
uninitialized variable, then you're accessing whatever random value it
happens to get.
I think the correct terminology would be "the value of the variable is
undefined", meaning that each implementation is free to use whatever
behavior it likes.
Most C implementations will (I believe) end up with random data in those
variables rather than taking the time to initialize them to some
recognizable value (although some implementations have done that), and
this can be a fruitful source of non-repeatable segmentation faults and
inexplicable behaviors.
The nice thing about Python's ability to create variables on assignment
is that you will either get an UnboundLocalError or a NameError or an
AttributeError exception if you try to access a name that hasn't been
defined. This nicely parallels KeyError and IndexError behavior with
container objects.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
On Nov 17, 7:35 pm, Craig Allen <callen...@gmail.comwrote:
>* Do all objects have values? (Ignore the Python
docs if necessary.)
If one allows null values, I am current thinking yes.
I don't see a difference between a "null value"
and not having a value.
I think the difference is concrete... an uninitialized variable in C
has no value, I'd say, because the value it will have is
indeterminate, it will be whatever happens to be sitting at that
location in memory, inconsistent. If that variable is initialized to
some value representing "none", like NULL, then it has a consistent
value of "none". There is no way to have an uninitialized variable in
python, so they are always consistently set, so they always have
values.
I wrote "I don't see a difference between a "null value"
and not having a value" in the specific context of "what
constitutes an object?" considering the Python Docs
definition of object as identity, type, and value. It
was that "value" (the characteristic of an object that
is left after you have considered id and type), that I
was referring to. I still see no difference between a
"null value" and "has no value" in that context.
Nothing (directly) to do with memory, variables, C,
parameter passing, None, etc.
I realize in hightsight that the word "value" is too strongly
overloaded with pre-existing semantics for many people to
accept it being redefined with a specific meaning in the
limited context of a description of Python objects. And it
was also pretty dumb of me to raise the issue in a contentious
thread about values in parameter passing. Live and learn....
Steven D'Aprano wrote:
On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:
For example, consider the two electrons around a helium nucleus. They
have the same mass, the same speed, the same spin, the same electric
charge, the same magnetic moment, they even have the same location in
space (technically, the same wave function).
By quantum mechanics (Pauli Exclusion principle), this is impossible.
They are identical in every
possible way. Are they the same electron, or two different electrons?
What does the question even mean?
That you do not understand QM?
Photons, on the other hand, can be identical, hence lasars.
Matter is divided into leptons and bosons, individualists and
communalists. (I believe I have the name right.)
>For example, you can define the value of None however you want, but it
seems clear that it has (and needs) no intrinsic-value.
To me, that seems just as silly as arguing that zero is not a number,
To me, that distortion of his (and my) point is silly. 0 partipipates
in numerous integer operations, whereas None participates in no NoneType
operations. (Neither has attributes.) And that is the difference he is
pointing at.
or that white pixels are "nothing" and black pixels are "something".
This is a ridiculous attempt at ridicule;-) Pixels have positions and 1
to 4 graded attributes. Completely different from None.
tjr
Terry Reedy wrote:
Steven D'Aprano wrote:
>On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:
>For example, consider the two electrons around a helium nucleus. They
have the same mass, the same speed, the same spin, the same electric
charge, the same magnetic moment, they even have the same location in
space (technically, the same wave function).
By quantum mechanics (Pauli Exclusion principle), this is impossible.
They are identical in every
possible way. Are they the same electron, or two different electrons?
What does the question even mean?
That you do not understand QM?
Photons, on the other hand, can be identical, hence lasars.
Matter is divided into leptons and bosons, individualists and
communalists. (I believe I have the name right.)
Fermions and bosons, actually.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
On Nov 18, 2:55*pm, Terry Reedy <tjre...@udel.eduwrote:
Steven D'Aprano wrote:
On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:
For example, consider the two electrons around a helium nucleus. They
have the same mass, the same speed, the same spin, the same electric
charge, the same magnetic moment, they even have the same location in
space (technically, the same wave function).
or that white pixels are "nothing" and black pixels are "something".
This is a ridiculous attempt at ridicule;-) *Pixels have positions and 1
to 4 graded attributes. *Completely different from None.
IINM if I'm not mistaken, portions of the retina are most excited in
the dark.
Same means one of two things. Either share an identity (continuity of
form), or high degree of similarity in structure and composition.
On a physical level, the electrical states of bit circuits in memory
are very similar in two "equal" bytes. Low voltage, low voltage, high
voltage.
Outside of the physical, the ideal, there is still such thing as
continuity. We have a memory:
M= { 0: [ 1, 2 ],
1: [ 1, 2 ] }
We can write an operation 'app( M, id, val )', which returns the
memory with the entry at id 'id' appended by 'val'. The bracket
operation ( M[ id ] ) returns the entry of the memory at id 'id'.
>>app( { 0: [ 1, 2 ], 1: [ 1, 2 ] }, 0, 3 )
{ 0: [ 1, 2, 3 ],
1: [ 1, 2 ] }
>>_[ 0 ]
[ 1, 2, 3 ]
Immutable types don't even need it. Identity serves no additional
purpose to value. That is, you can pick either tuple ( 1, 2 ), ( 1,
2 ) out of a bag with both in it, and operate.
With side-effects come mutable types, and identity and value diverge.
I think you can make a case that type is an entry in value, leaving
identity and value in general. Then, identity just means, what
original expression an object is continuous with, and value is the
original expression plus subsequent mutations.
Logical matter can be created and destroyed, which clarifies some of
the issues about composition and identity.
Now go away, before I taunt you a second time.
Antoon Pardon wrote:
Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.
You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.
But many other language designers, of both static and
dynamic languages, have done just that.
I'm not saying it *has* to be interpreted that way,
just that it *is* very often interpreted that way.
So you can't claim that it's not common usage.
If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term
Not at all. It very concisely conveys how parameters
are passed, once you know how assignment works -- and
you need to understand that in any case.
--
Greg This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Liming |
last post by:
Hello all,
I have a custom class object with some prototype methods like
setKeyDownEvent, etc.
The problem is on my webpage, after I instantiate the class, I try to
do .addEventLister() to a...
|
by: Brad Baker |
last post by:
I am trying to programmatically set a placeholder control in csharp which is
nested inside a repeater control between <ItemTemplateand </ItemTemplate>
tags, however I am running into problems. I've...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| |
