About the implementation of del in Python 3
On Fri, Jul 7, 2017 at 7:10 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Steve D'Aprano <steve+python at pearwood.info>:
>> An address is a concrete location or place, in other words a physical
>> position in some space, while identity is the abstract state or
>> quality of being identical (sameness), in other words a state of
> Whether id() returns one such thing or not can't be discerned by a
> Python program. What's more, for any compliant implementation of id(),
> you can interpret the returned number as an address in some address
> space (whether it's useful or not to interpret it that way).
And I can interpret "Marko Rauhamaa" as a MIME-encoded IPv6 address.
Does that mean it is one?
This is clearly your identity, and your address.
>> In full generality, I doubt that there is any definition of "identity"
>> which can be fully satisfactory, but in the context of Python we can
>> be more specific:
>> Nominally two objects are identical (have the same identity) if they
>> are one and the same object, and are not identical if they are
>> different objects.
> I believe identity can be defined much better, in numerous isomorphic
> ways in fact.
> For example, we could equate each object with a sequence number
> (unrelated with its id()). You can define that the "None" object is in
> fact the natural number 0. The "False" object is in fact the natural
> number 1 etc for all the primordial objects. During the execution of the
> program, new objects are created, which simply associates
> characteristics to ever higher natural numbers.
That's pretty much how Jython assigns IDs. However, it does not assign
them when objects are created, but when they're first passed to id().
>>> lists = [, , , , ]
>>> lists is lists
In the Jython world, the ID of an object is an attribute of it.
Objects can have identity (and be tested for identity with 'is')
without having IDs. So identity is not defined in terms of ID, but ID
in terms of identity.
>> Why do you have to generalise it? The name "a" here stands in for any
>> reference to any object.
> "Any reference to any object" is difficult to define syntactically as
> the reference itself might perform some dunder magic.
A simple name lookup cannot, I believe, be messed with. Nor can a literal.
> For example, you can't say that necessarily
> x.y is x.y
No, that's right, any more than you would expect
 is 
to be true. These are expressions that (can potentially) construct new
objects. But if you can show me a situation in which "a is a" is
False, I would be very surprised.
> No, just trying to emphasize the difference between syntax and semantics.
> "a is a"
> is a specific, legal statement in Python.
And it means "the object bound to the name 'a' is the same as the
object bound to the name 'a'". If there's no such object, it's not the
same as itself, in the same way that float("nan") is not equal to
itself - in each case, there is no "itself" (with floats, that's a
matter of value, rather than identity, but the same concept applies).
> We could generalize and say (wrongly) that
> "X is X"
> where X stands for any legal Python expression, is always true. However,
> X might be undefined or produce side effects.
You can always overgeneralize. So? I could generalize and say that "a
is a" is a specific, legal statement in APL, since it's valid and
meaningful in Python. Doesn't really mean much.
>> "x is y is true if and only if x and y are the same object."
> I suppose what is meant is the above:
> ?X ? ? ?Y ? ? ?(concat(X, "is", Y)) = 1 ? ?(X) ? ?(Y)
.... yeah I think I prefer the version in the docs. It's pretty clear
what it means. I've no idea what you're saying here with all that
concatenation and stuff, but the truth is way simpler. If the two
sides are the same object, 'is' returns true. Seriously, what's not