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

Bryan Olson fakeaddress at
Sun Jan 15 09:36:01 CET 2006

Mike Meyer wrote:
> Bryan Olson <fakeaddress at> writes:
>>Mike Meyer wrote:
>>>Bryan Olson <fakeaddress at> writes:
>>>>Mike Meyer wrote:
>>>>>Bryan Olson writes:
>>>>The Python manual's claim there is solidly grounded. The logic
>>>>of 'types' is reasonably well-defined in the discipline. Each
>>>>instance of a type takes exactly one element from the type's
>>>>set of values (at least at a particular time).
>>Are not hard to find.
> Well, Google didn't turn anything up. On the other hand, "object" and
> "value" are pretty poor terms to google with. Maybe you can suggest
> better ones?

Didn't I?  "Type", or "data type" or "datatype", plus "abstract

>>In Niklaus Wirth's /Algorithms + Data
>>Structures = Programs", the first section after "introduction"
>>"The concept of data type".
> It's been a few decades since I read that, but I don't recall anything
> that prohibited a valueless instance.

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

>>Wikipedia has reasonable articles on datatype and abstract
>>datatype. That an instance takes a value is too obvious to state,
>>but clearly implied by discussion of an object's value.
> I obviously disagree that it's too obvious to state. Just because most
> instances of objects have a value doesn't necessarily mean that every
> instance of an object has a value.

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

 > The discussion on these wikipedia
> pages don't say anything that would imply that an object must have a
> value.
>>If you're familiar with other programming
>>languages, you can to those. There are no values of C's 'void'
>>type, and consequently there are never any objects of type void.
> But we're not talking about C, we're talking about Python.

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

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


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

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

>>>>Maybe I was wrong, and the object's identity
>>>>is part of its abstract state.
>>>Is abstract state always part of the value?
>>The abstract state, sometimes called the "logical state", is
>>the value the object represents.
> So are you now claiming that all instances of object have different
> values, as they all have different identities?

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

>>The concept of a valueless object is inconsistent with a great deal
> Another completely unsupported pronouncement.   *What* material? Come
> on, give me *explicit* references.

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

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

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

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

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

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

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


More information about the Python-list mailing list