[Tutor] beginning to code

Chris Angelico rosuav at gmail.com
Sat Sep 23 18:35:48 EDT 2017


On Sun, Sep 24, 2017 at 8:18 AM, Bill <BILL_NOSPAM at whoknows.net> wrote:
> Stephan Houben wrote:
>>
>> Op 2017-09-23, Rick Johnson schreef <rantingrickjohnson at gmail.com>:
>>>
>>> These pissing contests over how values are passed in Python
>>> are totally irrelevant. What does it matter? Nothing will be
>>> gained or lost by arguing over which is true, or not. Unless
>>> the distinction is preventing you from doing something that
>>> you'd like to do, or unless you want to argue that one
>>> "value passing method" would bring X, Y or Z benefits over
>>> the other, what does it matter?
>>
>> Amen.
>>
>
> All one has to do, I think, is consider (1) that passing objects by "making
> copies" of them, would be prohibitively expensive and consider that
> something else has to happen as an alternative, and (2) understand that in
> Python, objects don't have names, they have references (which have names).
> The rest could be "implementation dependent" (no?)   To be amusing, how did
> the chicken pass an egg to the_other_side_of_the_road(e)?  Could the egg get
> crushed (stay tuned)?

Actually they don't "have" references in any real sense of possession.
An object "has" things like its type, its attributes, etc etc; if you
have a reference to an object, you can query it for its type. But you
can't ask an object if there's a reference to it over here or there.
(Yes, I know that sys.getrefcount exists in CPython, but this isn't
part of the language's definition. Also, even that is just a counter -
you can't find specific references.) An object may have a reference to
other objects (eg a list's contents), but it's a one-way thing -
there's no way to find all the references to this object.

So more accurate would be to say that objects don't have names, but
names refer to objects. When you assign to a simple name, you cause
that name to refer to the object you gave it.

ChrisA



More information about the Python-list mailing list