About the implementation of del in Python 3

[Chris Angelico]

On Fri, Jul 7, 2017 at 3:05 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> On Fri, Jul 7, 2017 at 1:21 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> What I'm looking for is snippets of Python code that illustrate the
>>> difference.
>>>
>>> That's how you can illustrate the difference between the "==" and "is"
>>> operators:
>>>
>>>     >>> ["a"] is ["a"]
>>>     False
>>>     >>> ["a"] == ["a"]
>>>     True
>>
>> When you have an address, you can use that to locate the thing.
>
> You are pulling that out of your hat (or a dictionary). Python doesn't
> define the concept at all (yet it manages to locate every useful thing
> there is).

That's right. Python does not use the term "address" as part of its
object model. So when you ask me to define it, all I can do is look
outside of Python.

There might be a reason for this. Like, maybe, that Python doesn't use
addresses in its object model.

>> In C, that's pointer dereferencing. If I give you the id of a Python
>> object, can you locate that object and find out something about it? If
>> you can't, it's not an address.
>>
>> And you have to make this work in Python (the language), not just
>> CPython (the interpreter). I'll consider an answer satisfactory if it
>> runs on the Big Four - CPython, Jython, IronPython, and PyPy - and
>> mainly, you need to show that it works in Jython, because that's the
>> most different.
>
> I don't follow you. A code example, please.

If I have the address of something in C, I can dereference that and
get at the data therein. Can you do that in Python? If you want to
claim that object identity is a form of address, you should be able to
show that it can be used as one.

>>>> First part is implied by Python's execution model,
>>>
>>> [Citation needed]
>>
>> https://docs.python.org/3/reference/executionmodel.html
>
> Sorry, which sentence?

I think you're probably missing some fundamentals of how Python works,
so have a read of the whole page.

>> https://docs.python.org/3/reference/expressions.html#is-not
>
> That one in its entirety:
>
>    The operators "is" and "is not" test for object identity: x is y is
>    true if and only if x and y are the same object. Object identity is
>    determined using the id() function. x is not y yields the inverse
>    truth value.
>
> That simply defines the identity with whatever is returned by the id()
> function.

No; it defines object identity as "are the same object", relying on
our external comprehension of identity. It then says that you can
coalesce the identity to an integer using the id() function.

> The id() function, in turn, is defined to be:
>
>    Return the “identity” of an object. This is an integer which is
>    guaranteed to be unique and constant for this object during its
>    lifetime. Two objects with non-overlapping lifetimes may have the
>    same id() value.
>
> which doesn't clarify anything.

If you start with object identity, the id() function makes sense given
the above definition. You cannot, however, use the id() function to
define object identity, since id values can be reused.

>> Just don't try explaining to a novice programmer that way. It's a
>> waste of everyone's time.
>
> I believe the concept of an object is among the more difficult things
> for novice programmers to get.

Maybe, for certain technical definitions of "object" (eg in Python,
everything is an object, but in JavaScript, an object is a mapping
type, as distinct from an array, except that an array is an object
too, and... yeah); but the concept of a "thing" is fairly well
understood. I have explained Python's object model to people using
physical things on my desk, and never had anyone go "but what's the
address of that thing". People grok Python's objects just fine when
you relate them to real-world objects. I can explain merge sort using
a deck of cards and my desk, I can explain the stack using the same
tools, and I can even explain stuff using vanilla-flavoured sugar -
because Python parallels our world beautifully.

(So do many other languages. I've explained JS to people the same way.
And I've never explained JS by starting with C.)

ChrisA