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

Mike Meyer mwm at
Sun Jan 15 14:29:58 CET 2006

Bryan Olson <fakeaddress at> writes:
> 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
> data[optional-space]type.

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

>>>In Niklaus Wirth's /Algorithms + Data
>>>Structures = Programs", the first section after "introduction"
>>>"The concept of data type".
>> It's been a few decades since I read that, but I don't recall
>> anything
>> that prohibited a valueless instance.
> The term "data type" implies instances have data; is it clear
> enough that a datum is a value?

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

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

*What* general principles? *What* results?

>  > The discussion on these wikipedia
>> pages don't say anything that would imply that an object must have a
>> value.
>>>If you're familiar with other programming
>>>languages, you can to those. There are no values of C's 'void'
>>>type, and consequently there are never any objects of type void.
>> But we're not talking about C, we're talking about Python.
> You seemed to disagree when I said "the logic of 'types'
> is reasonably well-defined in the discipline". If you're
> just talking about Python, then the Python Language
> Reference is right simply by status.

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

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

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

> [...]
>> Ok, so the objects identity is not it's value.
> Right.
>> Otherwise, the claim
>> "the type object has only one value" would be false.
> I'm still not sure that there's only one value for
> objects of type 'object'.

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

>>>The concept of a valueless object is inconsistent with a great deal
>> Another completely unsupported pronouncement.   *What* material? Come
>> on, give me *explicit* references.
> My textbooks are in storage too, but you'll find plenty if
> you look. Remember learning about "call by value"? Did they
> have to deal with objects without a value to pass?

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

> Discussion involving an object's value would have to be rewritten
> to cover the case of objects that don't have one. Is a valueless
> object mutable or immutable? Let's see; the Reference says:
>      Objects whose value can change are said to be mutable;
>      objects whose value is unchangeable once they are created
>      are called immutable.
> Your valueless objects break the definitions. The Ref says
> "An object's mutability is determined by its type" so it
> must have some mutability status to determine. Want to
> re-work the literature to cover your special case?

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

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

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

>  > At the very least, provide or point
>> to a definition of type that makes it clear that a type for which you
>> can have instances *has* to have values.
> Did the references make clear to you that this usage of 'type'
> means 'data type'?

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

Mike Meyer <mwm at>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

More information about the Python-list mailing list