Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Ethan Furman]

On 03/25/2016 06:03 AM, Albert-Jan Roskam wrote:
> Somebody wrote:
>> Somebody else wrote:


I know Python does not have variables, but names.
Multiple names cant then be bound to the same objects.

So this behavior

--> b = 234
--> v = 234
--> b is v
True

according to the above that is ok



But where is the consistency ? if I try :

--> v = 890
--> w = 890
--> v is w
False

It is a little difficult to explain this behavior to a newcommer in Python

Can someone give me the right argument to expose ?


You should not bother with object identity for objects other than None.


No.  The correct answer is: if identity is important either ensure the 
object you are getting back is a singleton (such as None, True, an Enum 
member, etc.) or you assign one name from another name:


--> b = 234
--> v = b
--> b is v
True
--> v = 890
--> w = v
--> v is w
True

If identity is not important, don't use `is`.


A little late to the party, but: how about Ellipsis? Shouldn't "is" also be 
used for that one? (It's rare, I know :))


Ellipsis is a singleton, so `is` is fine.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Chris Angelico]

On Sat, Mar 26, 2016 at 12:03 AM, Albert-Jan Roskam
 wrote:
>> You should not bother with object identity for objects other than None.
>
>
> A little late to the party, but: how about Ellipsis? Shouldn't "is" also be 
> used for that one? (It's rare, I know :))

Yes, and also True and False, if you're checking for the specific
values. (Though it's more common in Python to merely care about
truthiness/falsiness.) Other common identity checks include:

if str is bytes:
# Python 2 handling, where "native strings" are byte strings
else:
# Python 3 handling, where "native strings" are text strings

if iter(x) is x:
# x is an iterator, not some other iterable

_SENTINEL = object()
def func(arg=_SENTINEL):
if arg is _SENTINEL:
# arg was not passed

Anyone who says that identity checks are only for None is
significantly over-simplifying things. This isn't necessarily a bad
thing, but it should never be taken to be the whole story.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Albert-Jan Roskam]

> To: python-list@python.org
> From: __pete...@web.de
> Subject: Effects of caching frequently used objects, was Re: Explaining  
> names  vs variables  in Python
> Date: Wed, 2 Mar 2016 10:12:48 +0100
> 
> Salvatore DI DIO wrote:
> 
> > Hello,
> > 
> > I know Python does not have variables, but names.
> > Multiple names cant then be bound to the same objects.
> > 
> > So this behavior
> > 
> >>>> b = 234
> >>>> v = 234
> >>>> b is v
> > True
> > 
> > according to the above that is ok
> > 
> > 
> > 
> > But where is the consistency ? if I try :
> > 
> >>>> v = 890
> >>>> w = 890
> >>>> v is w
> > False
> > 
> > It is a little difficult to explain this behavior to a newcommer in Python
> > 
> > Can someone give me the right argument to expose ?
> 
> You should not bother with object identity for objects other than None.


A little late to the party, but: how about Ellipsis? Shouldn't "is" also be 
used for that one? (It's rare, I know :))
Albert-Jan

  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Ian Kelly]

On Thu, Mar 3, 2016 at 10:03 AM, Rustom Mody  wrote:
> Is it so damn hard to be a bit honest and when asked about is in python to 
> reply:
>
> If you dont know what you are doing, dont use 'is' (None excepted)
> If you know why are you asking?

That seems like a rather unhelpful response.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Rustom Mody]

On Thursday, March 3, 2016 at 7:22:43 AM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 3 Mar 2016 05:12 am, Marko Rauhamaa wrote:
> 
> > Steven D'Aprano :
> > 
> >> In this case, "same object" carries the normal English meaning of
> >> "same" and the normal computer science meaning of "object" in the
> >> sense of "Object Oriented Programming". There's no mystery here, no
> >> circular definition.
> > 
> > I see three possible ways of defining "is" / object identity (and other
> > concepts):
> > 
> >1. hand waving ("normal English")
> > 
> >2. reduction to an underlying model (a real / conceptual computer)
> > 
> >3. formal semantics
> > 
> > All methods are in use. Experienced programmers have #2 in mind but are
> > embarrassed to admit they understand Python through C. Thus, they offer
> > explanation #1 to newbies, who are too embarrassed to admit they don't
> > get the explanation.
> 
> There is no evidence that newbies "don't get the explanation". Completely
> the opposite: newbies frequently find the behaviour of `is` mysterious[1]
> *until* it is explained to them in terms of "same object", after which it
> becomes clear. (At least for those who understand what "object" means in
> OOP terms.)
> 
> And then the same two people, you and Rustom, come along and insist that the
> docs don't define `is` correctly and raising irrelevant philosophical
> objections. But there's no evidence that these issues are the least bit
> relevant to the newbies who asked the questions in the first place.

And now your English use of "same" in "same two people" is getting mysterious.
If you are suggesting that Marko are Rustom are the same person... that's 
mystical. [Maybe we should calculate their weight ? ]

If I try to find a less far out meaning, I need to find some other something
by Marko and/or Rustom...  What??

And then there's Terry:

| The 'is' operator has three uses, two intended and one not. In 
| production code, 'is' tests that an object *is* a particular singular 
| object, such as None or a sentinel instance of class object. In test 
| code, 'is' can also be used to test details of a particular 
| implementation, such as pre-allocation of small ints. New python 
| programmers also use it to confuse themselves.

>From https://mail.python.org/pipermail/python-list/2014-March/668136.html

And Peter Otten further up this same thread:
> You should not bother with object identity for objects other than None.

which, sotto voce, is saying much the same as Terry.

Is it so damn hard to be a bit honest and when asked about is in python to 
reply:

If you dont know what you are doing, dont use 'is' (None excepted)
If you know why are you asking?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Mark Lawrence]

On 03/03/2016 02:05, Steven D'Aprano wrote:

On Thu, 3 Mar 2016 08:49 am, Mark Lawrence wrote:


On 02/03/2016 17:23, Steven D'Aprano wrote:

On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:


What is missing is the rules that are obeyed by the "is" operator.


I think what is actually missing is some common bloody sense. The Python
docs are written in English, and don't define *hundreds*, possible
*thousands* of words because they are using their normal English meaning.

The docs for `is` say:

6.10.3. Identity comparisons

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. x is not y yields the inverse
truth value.

https://docs.python.org/3/reference/expressions.html#is-not

In this case, "same object" carries the normal English meaning of "same"
and the normal computer science meaning of "object" in the sense of
"Object Oriented Programming". There's no mystery here, no circular
definition.



Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
Canadian, South African, Australian, New Zealand, or some other form of
English?


To the best of my knowledge, `is` has the same meaning in all variants of
English (although there are sometimes differences in grammatical form,
e.g. "this be that" versus "this is that"). It is a very old word, and such
old words tend to have astonishingly stable semantics and irregular
spelling.

https://en.wiktionary.org/wiki/is#English
https://en.wiktionary.org/wiki/be#English



That's all right then.

Perhaps we can now get back to the OP's question and not some bloody 
stupid philosophical discussion.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Steven D'Aprano]

On Thu, 3 Mar 2016 08:49 am, Mark Lawrence wrote:

> On 02/03/2016 17:23, Steven D'Aprano wrote:
>> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:
>>
>>> What is missing is the rules that are obeyed by the "is" operator.
>>
>> I think what is actually missing is some common bloody sense. The Python
>> docs are written in English, and don't define *hundreds*, possible
>> *thousands* of words because they are using their normal English meaning.
>>
>> The docs for `is` say:
>>
>> 6.10.3. Identity comparisons
>>
>> 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. x is not y yields the inverse
>> truth value.
>>
>> https://docs.python.org/3/reference/expressions.html#is-not
>>
>> In this case, "same object" carries the normal English meaning of "same"
>> and the normal computer science meaning of "object" in the sense of
>> "Object Oriented Programming". There's no mystery here, no circular
>> definition.
>>
> 
> Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
> Canadian, South African, Australian, New Zealand, or some other form of
> English?

To the best of my knowledge, `is` has the same meaning in all variants of
English (although there are sometimes differences in grammatical form,
e.g. "this be that" versus "this is that"). It is a very old word, and such
old words tend to have astonishingly stable semantics and irregular
spelling.

https://en.wiktionary.org/wiki/is#English
https://en.wiktionary.org/wiki/be#English



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Steven D'Aprano]

On Thu, 3 Mar 2016 05:12 am, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> In this case, "same object" carries the normal English meaning of
>> "same" and the normal computer science meaning of "object" in the
>> sense of "Object Oriented Programming". There's no mystery here, no
>> circular definition.
> 
> I see three possible ways of defining "is" / object identity (and other
> concepts):
> 
>1. hand waving ("normal English")
> 
>2. reduction to an underlying model (a real / conceptual computer)
> 
>3. formal semantics
> 
> All methods are in use. Experienced programmers have #2 in mind but are
> embarrassed to admit they understand Python through C. Thus, they offer
> explanation #1 to newbies, who are too embarrassed to admit they don't
> get the explanation.

There is no evidence that newbies "don't get the explanation". Completely
the opposite: newbies frequently find the behaviour of `is` mysterious[1]
*until* it is explained to them in terms of "same object", after which it
becomes clear. (At least for those who understand what "object" means in
OOP terms.)

And then the same two people, you and Rustom, come along and insist that the
docs don't define `is` correctly and raising irrelevant philosophical
objections. But there's no evidence that these issues are the least bit
relevant to the newbies who asked the questions in the first place.


> I think #3 could be tried more often. 

I completely agree! It could be tried more often!

Other things that could be tried more often include:

- defining `is` through the medium of interpretive dance;

- defining `is` by wafting information-rich pheromones through the air;

- defining `is` by taking copious amounts of hallucinogens until your mind
becomes one with the universe and you intuitively understand everything.

But I think that in the case of Python, a combination of #1 and #2 are
needed.

(I think that nearly all people need to have some sort of concrete picture
in their heads for an object, even if they then go on to consciously reject
that picture as "just an implementation detail". Objects are not
necessarily C structs with a pointer back to a struct which represents the
object's class, but that's a common implementation.)



> It is analogous to providing the 
> BNF of Python's syntax (which *is* done:  https://docs.python.org/3/reference/grammar.html>).

BNF is for describing syntax, not semantics. Nobody has trouble with the
syntax of `is`, it is a simple binary operator. There is no analogous
BNF-equivalent for semantics.





[1] Usually because they are either interpreting it as a synonym for
equality, or because they are confused by Python's caching of small ints
and some strings.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Rustom Mody]

On Thursday, March 3, 2016 at 3:22:42 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence  wrote:
> > Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
> > Canadian, South African, Australian, New Zealand, or some other form of
> > English?
> 
> Is there any disagreement among them about the word "same"?

So same is same
But is is not is?

IOW if we dont need to explain same why do we need to explain is?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Mark Lawrence]

On 02/03/2016 21:52, Chris Angelico wrote:

On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence  wrote:

Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
Canadian, South African, Australian, New Zealand, or some other form of
English?


Is there any disagreement among them about the word "same"?

ChrisA



How the hell would I know?  Have you ever tried speaking to a Glaswegian 
or a Geordie?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Chris Angelico]

On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence  wrote:
> Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
> Canadian, South African, Australian, New Zealand, or some other form of
> English?

Is there any disagreement among them about the word "same"?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Mark Lawrence]

On 02/03/2016 17:23, Steven D'Aprano wrote:

On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:


What is missing is the rules that are obeyed by the "is" operator.


I think what is actually missing is some common bloody sense. The Python
docs are written in English, and don't define *hundreds*, possible
*thousands* of words because they are using their normal English meaning.

The docs for `is` say:

6.10.3. Identity comparisons

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. x is not y yields the inverse truth
value.

https://docs.python.org/3/reference/expressions.html#is-not

In this case, "same object" carries the normal English meaning of "same" and
the normal computer science meaning of "object" in the sense of "Object
Oriented Programming". There's no mystery here, no circular definition.



Are we discussing UK (highly generalised), Geordie, Glaswegian, US, 
Canadian, South African, Australian, New Zealand, or some other form of 
English?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Marko Rauhamaa]

Steven D'Aprano :

> In this case, "same object" carries the normal English meaning of
> "same" and the normal computer science meaning of "object" in the
> sense of "Object Oriented Programming". There's no mystery here, no
> circular definition.

I see three possible ways of defining "is" / object identity (and other
concepts):

   1. hand waving ("normal English")

   2. reduction to an underlying model (a real / conceptual computer)

   3. formal semantics

All methods are in use. Experienced programmers have #2 in mind but are
embarrassed to admit they understand Python through C. Thus, they offer
explanation #1 to newbies, who are too embarrassed to admit they don't
get the explanation.

I think #3 could be tried more often. It is analogous to providing the
BNF of Python's syntax (which *is* done: https://docs.python.org/3/reference/grammar.html>).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Ben Finney]

Salvatore DI DIO  writes:

> I know Python does not have variables, but names.

In addition to the other food answers in this thread, you will want to
watch  Ned Batchelder's
presentation on “Facts and myths about Python names and values”.

-- 
 \“Members of the general public commonly find copyright rules |
  `\implausible, and simply disbelieve them.” —Jessica Litman, |
_o__)  _Digital Copyright_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Rustom Mody]

On Wednesday, March 2, 2016 at 10:53:40 PM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:
> 
> > What is missing is the rules that are obeyed by the "is" operator.
> 
> I think what is actually missing is some common bloody sense. The Python
> docs are written in English, and don't define *hundreds*, possible
> *thousands* of words because they are using their normal English meaning.
> 
> The docs for `is` say:
> 
> 6.10.3. Identity comparisons
> 
> 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. x is not y yields the inverse truth
> value.
> 
> https://docs.python.org/3/reference/expressions.html#is-not
> 
> 
> In this case, "same object" carries the normal English meaning of "same" and
> the normal computer science meaning of "object" in the sense of "Object
> Oriented Programming". There's no mystery here, no circular definition.
> 

http://plato.stanford.edu/entries/identity/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Steven D'Aprano]

On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:

> What is missing is the rules that are obeyed by the "is" operator.

I think what is actually missing is some common bloody sense. The Python
docs are written in English, and don't define *hundreds*, possible
*thousands* of words because they are using their normal English meaning.

The docs for `is` say:

6.10.3. Identity comparisons

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. x is not y yields the inverse truth
value.

https://docs.python.org/3/reference/expressions.html#is-not


In this case, "same object" carries the normal English meaning of "same" and
the normal computer science meaning of "object" in the sense of "Object
Oriented Programming". There's no mystery here, no circular definition.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Steven D'Aprano]

On Thu, 3 Mar 2016 12:48 am, Chris Angelico wrote:

> On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>
>>> Python defines that every object has an identity, which can be
>>> represented as an integer. Since this is an intrinsic part of the
>>> object, no two distinct objects can truly have identical
>>> characteristics. Python's objects are like rifles - there are many
>>> like it, but this one is mine.
>>
>> How can you be sure Python isn't returning the same id value for two
>> distinct objects?

The language is entitled to re-use IDs provided the objects do not exist at
the same time. So there certainly will be times that Python will return the
same ID for different objects:

py> id([1])
3083419340L
py> id([2])
3083419340L



> The same way I can be sure about anything else in Python. It's a
> language guarantee. If you're bothered by that, you should also be
> concerned that str(x) might not actually call x.__str__(), 

Technically, it doesn't, it calls type(x).__str__() (at least in Python 3
and new-style classes in 2) :-)


But your point is broadly correct: you trust the language to do what it
promises, or you look for evidence that it doesn't and report a bug if you
find it.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Jussi Piitulainen]

Ian Kelly writes:

> On Wed, Mar 2, 2016 at 2:35 AM, Jussi Piitulainen wrote:
>> The following are too delicate for me. I suppose the answers could have
>> been different, but I can't guess what mechanism actually leads to these
>> results. Just idle curiosity on my part.
>>
> 890 is 890
>> True
> id(890) == id(890)
>> True
>
> This has to do with the way code blocks are compiled. In the
> interactive interpreter, a single line like '890 is 890' is compiled
> to a single code object. The constant 890 appears twice in the same
> code block, so the optimizer uses the same constant for both. Note in
> the following that the same index appears for both, so they're
> actually the same object reference.

No wonder my guesses failed. This is different.

 import dis
 dis.dis('890 is 890')
>   1   0 LOAD_CONST   0 (890)
>   3 LOAD_CONST   0 (890)
>   6 COMPARE_OP   8 (is)
>   9 RETURN_VALUE
 compile('890 is 890', '', 'exec').co_consts
> (890, None)
>
>
> As for the earlier example of:
>
> 1 + 1 is 2
>> True
> 800 + 90 + 0 is 890
>> False
>
> This one actually surprises me a little, because the optimizer is also
> smart enough to evaluate '800 + 90 + 0' and just store a constant of
> 890:
>
 dis.dis('800 + 90 + 0 is 890')
>   1   0 LOAD_CONST   5 (890)
>   3 LOAD_CONST   3 (890)
>   6 COMPARE_OP   8 (is)
>   9 RETURN_VALUE
 compile('800 + 90 + 0 is 890', '', 'exec').co_consts
> (800, 90, 0, 890, None, 890, 890)
>
> Not smart enough to reuse the existing reference in this case
> apparently, or even to prune out the original constants that are no
> longer used in the code.

So it has access to three 890-objects and compares two of them :)

Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Ian Kelly]

On Wed, Mar 2, 2016 at 2:35 AM, Jussi Piitulainen
 wrote:
> The following are too delicate for me. I suppose the answers could have
> been different, but I can't guess what mechanism actually leads to these
> results. Just idle curiosity on my part.
>
 890 is 890
> True
 id(890) == id(890)
> True

This has to do with the way code blocks are compiled. In the
interactive interpreter, a single line like '890 is 890' is compiled
to a single code object. The constant 890 appears twice in the same
code block, so the optimizer uses the same constant for both. Note in
the following that the same index appears for both, so they're
actually the same object reference.

>>> import dis
>>> dis.dis('890 is 890')
  1   0 LOAD_CONST   0 (890)
  3 LOAD_CONST   0 (890)
  6 COMPARE_OP   8 (is)
  9 RETURN_VALUE
>>> compile('890 is 890', '', 'exec').co_consts
(890, None)


As for the earlier example of:

 1 + 1 is 2
> True
 800 + 90 + 0 is 890
> False

This one actually surprises me a little, because the optimizer is also
smart enough to evaluate '800 + 90 + 0' and just store a constant of
890:

>>> dis.dis('800 + 90 + 0 is 890')
  1   0 LOAD_CONST   5 (890)
  3 LOAD_CONST   3 (890)
  6 COMPARE_OP   8 (is)
  9 RETURN_VALUE
>>> compile('800 + 90 + 0 is 890', '', 'exec').co_consts
(800, 90, 0, 890, None, 890, 890)

Not smart enough to reuse the existing reference in this case
apparently, or even to prune out the original constants that are no
longer used in the code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Rustom Mody]

On Wednesday, March 2, 2016 at 7:42:09 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> 
> > On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa  wrote:
> >> Chris Angelico :
> >>
> >>> Python defines that every object has an identity, which can be
> >>> represented as an integer. Since this is an intrinsic part of the
> >>> object, no two distinct objects can truly have identical
> >>> characteristics. Python's objects are like rifles - there are many
> >>> like it, but this one is mine.
> >>
> >> How can you be sure Python isn't returning the same id value for two
> >> distinct objects?
> >
> > The same way I can be sure about anything else in Python. It's a
> > language guarantee.
> 
> Actually, my question is (intentionally) nonsensical.
> 
> The sameness or distinctness of two objects is not directly defined in
> Python. The definition is simply:
> 
>Two objects X and Y are called identical if
> 
>X is Y
> 
>evaluates to a true value.
> 
> Additionally, we have:
> 
>If objects X and Y are identical, it is guaranteed that
> 
>   id(X) == id(Y)
> 
>evaluates to a true value.
> 
> Even more strongly, we have:
> 
>For any objects X and Y,
> 
>   id(X) == id(Y) if X is Y else id(X) != id(Y)
> 
>evaluates to a true value.
> 
> What is missing is the rules that are obeyed by the "is" operator.

is is not is
is is was
[fermionic or bosonic?]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa  wrote:
>> Chris Angelico :
>>
>>> Python defines that every object has an identity, which can be
>>> represented as an integer. Since this is an intrinsic part of the
>>> object, no two distinct objects can truly have identical
>>> characteristics. Python's objects are like rifles - there are many
>>> like it, but this one is mine.
>>
>> How can you be sure Python isn't returning the same id value for two
>> distinct objects?
>
> The same way I can be sure about anything else in Python. It's a
> language guarantee.

Actually, my question is (intentionally) nonsensical.

The sameness or distinctness of two objects is not directly defined in
Python. The definition is simply:

   Two objects X and Y are called identical if

   X is Y

   evaluates to a true value.

Additionally, we have:

   If objects X and Y are identical, it is guaranteed that

  id(X) == id(Y)

   evaluates to a true value.

Even more strongly, we have:

   For any objects X and Y,

  id(X) == id(Y) if X is Y else id(X) != id(Y)

   evaluates to a true value.

What is missing is the rules that are obeyed by the "is" operator.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Chris Angelico]

On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Python defines that every object has an identity, which can be
>> represented as an integer. Since this is an intrinsic part of the
>> object, no two distinct objects can truly have identical
>> characteristics. Python's objects are like rifles - there are many
>> like it, but this one is mine.
>
> How can you be sure Python isn't returning the same id value for two
> distinct objects?

The same way I can be sure about anything else in Python. It's a
language guarantee. If you're bothered by that, you should also be
concerned that str(x) might not actually call x.__str__(), or that
a+b*c might evaluate the addition before the multiplication.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Marko Rauhamaa]

Chris Angelico :

> Python defines that every object has an identity, which can be
> represented as an integer. Since this is an intrinsic part of the
> object, no two distinct objects can truly have identical
> characteristics. Python's objects are like rifles - there are many
> like it, but this one is mine.

How can you be sure Python isn't returning the same id value for two
distinct objects?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Jussi Piitulainen]

Chris Angelico  writes:

> Python defines that every object has an identity, which can be
> represented as an integer. Since this is an intrinsic part of the
> object, no two distinct objects can truly have identical
> characteristics. Python's objects are like rifles - there are many
> like it, but this one is mine.

Rifles are not mines. A rifle hurts you from a distance. A mine hurts
you when you step on it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Chris Angelico]

On Wed, Mar 2, 2016 at 11:34 PM, Marko Rauhamaa  wrote:
> The ontological question is, can two *distinct* objects with *identical*
> characteristics exist?
>
> The fermionic answer is, no.
>
> The bosonic answer is, sure.
>
> Set theory has fermionic ontology (it's called extensionality).
>
> Python sits on the fence on that one, allowing either ontology.

Python defines that every object has an identity, which can be
represented as an integer. Since this is an intrinsic part of the
object, no two distinct objects can truly have identical
characteristics. Python's objects are like rifles - there are many
like it, but this one is mine.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Marko Rauhamaa]

Steven D'Aprano :

> On Wed, 2 Mar 2016 08:03 pm, Jesper K Brogaard wrote:
>
>> As I understand it, when you use 'is', you are comparing addresses to
>> objects, not the values contained in the objects. Use '==' instead.
>
> You should not think about addresses, because the location of objects
> is not part of the language. It is implementation-dependent.

The ontological question is, can two *distinct* objects with *identical*
characteristics exist?

The fermionic answer is, no.

The bosonic answer is, sure.

Set theory has fermionic ontology (it's called extensionality).

Python sits on the fence on that one, allowing either ontology.

> This is why the id() function is NOT documented as returning the
> address of an object, but of returning an ID number. Let's look at IDs
> in IronPython:
>
 a, b, c = [], 1, "Hello world!"
 print id(a), id(b), id(c), id(None)
> 43 44 45 0
>
>
> And in Jython:
>
 a, b, c = [], 1, "Hello world!"
 print id(a), id(b), id(c), id(None)
> 1 2 3 4

Python doesn't define or use the concept of an "address."


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Salvatore DI DIO]

Thank you very much ast and all of you. 

I better understant now

Regards

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[ast]

"Salvatore DI DIO"  a écrit dans le message de 
news:a894d5ed-d906-4ff7-a537-32bf0187e...@googlegroups.com...



It is a little difficult to explain this behavior to a newcommer in Python
Can someone give me the right argument to expose ?



It is explained with many details here:
http://blog.lerner.co.il/why-you-should-almost-never-use-is-in-python/ 


--
https://mail.python.org/mailman/listinfo/python-list

Explaining names vs variables in Python (follow)

[Salvatore DI DIO]

Thank you very much all of you.
I better understand now

Regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Steven D'Aprano]

On Wed, 2 Mar 2016 08:03 pm, Jesper K Brogaard wrote:

> As I understand it, when you use 'is', you are comparing addresses to
> objects, not the values contained in the objects. Use '==' instead.

You should not think about addresses, because the location of objects is not
part of the language. It is implementation-dependent.

In CPython, objects are fixed to a single location in the heap, and will
never move. But in Jython and IronPython, objects in the python layer are
based on JVM (Java Virtual Machine) and CLR (Common Language Runtime)
objects, which can move around in memory. Both the JVM and the CLR can move
objects, so the location is not constant. Likewise for PyPy, which can
delete and re-create objects behind the scenes, possibly in different
memory locations.

This is why the id() function is NOT documented as returning the address of
an object, but of returning an ID number. Let's look at IDs in IronPython:

>>> a, b, c = [], 1, "Hello world!"
>>> print id(a), id(b), id(c), id(None)
43 44 45 0


And in Jython:

>>> a, b, c = [], 1, "Hello world!"
>>> print id(a), id(b), id(c), id(None)
1 2 3 4




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Steven D'Aprano]

On Wed, 2 Mar 2016 07:32 pm, Salvatore DI DIO wrote:

> Hello,
> 
> I know Python does not have variables, but names.
> Multiple names cant then be bound to the same objects.

Multiple names CAN be bound to the same object:

py> x = y = []
py> x is y
True
py> z = x
py> y.append("Hello world!")
py> z
['Hello world!']


So that is *three* names bound to the same list object.


> So this behavior
> 
 b = 234
 v = 234
 b is v
> True
> 
> according to the above that is ok

When I try that in different versions of Python, I get different results:

# Python 2.4
py> b = 234
py> v = 234
py> b is v
False

What you are seeing is a version-dependent optimization. Not all versions of
Python will behave the same way. The reason you can do that is that
integers are immutable objects and cannot be modified. So the Python
interpreter will cache some integers, and avoid creating new objects. So:

py> a, b = 50, 
py> c, d = 50, 
py> a is c  # the same object is reused for 50 each time
True
py> c is d  # new int objects are created for  each time
False


In Python 2.7, I think that the interpreter caches small ints from -1 to
255. But do not rely on this, because it is just an optimization and can
and will change from version to version.

You should never use `is` to test for equality. Use == to test for equality.
Use `is` *only* to test for object identity ("the same object").



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Jussi Piitulainen]

Salvatore DI DIO writes:

[- -]

> But where is the consistency ? if I try :
>
 v = 890
 w = 890
 v is w
> False

I think it goes as follows.

Python keeps a cached pool of some numbers that may occur relatively
often. When a numerical expression evaluates to a cached value, it
returns the cached object instead.

>>> 1 + 1 is 2
True
>>> 800 + 90 + 0 is 890
False

This way programs don't fill the memory with a large number of copies of
frequently occurring numbers like 2, and also don't keep rare numbers
like 890 around in the cache unnecessarily.

Python doesn't keep track of how often numbers actually occur. I think
it considers 0, 1, 2, ..., n, up to some rather small n, heuristically
frequent, and that's it. Also, this is an implementation detail.

Hm, -5, -4, -3, -2, -1 also seem cached when I try them, but -6 not.

The following are too delicate for me. I suppose the answers could have
been different, but I can't guess what mechanism actually leads to these
results. Just idle curiosity on my part.

>>> 890 is 890
True
>>> id(890) == id(890)
True

>>> 890 is 891
False
>>> id(890) == id(891)
False

Python 3.4.3 (default, Oct 14 2015, 20:33:09) 
[GCC 4.8.4] on linux
-- 
https://mail.python.org/mailman/listinfo/python-list

Effects of caching frequently used objects, was Re: Explaining names vs variables in Python

[Peter Otten]

Salvatore DI DIO wrote:

> Hello,
> 
> I know Python does not have variables, but names.
> Multiple names cant then be bound to the same objects.
> 
> So this behavior
> 
 b = 234
 v = 234
 b is v
> True
> 
> according to the above that is ok
> 
> 
> 
> But where is the consistency ? if I try :
> 
 v = 890
 w = 890
 v is w
> False
> 
> It is a little difficult to explain this behavior to a newcommer in Python
> 
> Can someone give me the right argument to expose ?

You should not bother with object identity for objects other than None.
Some small integers are used a lot, e. g.

Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getrefcount(0)
606
>>> sys.getrefcount(1)
918
>>> sys.getrefcount(256)
31
>>> sys.getrefcount(-1)
51

therefore as an optimization the Python developers decided to put -5...256 
(actual range may vary across interpreter versions) into a cache and reuse 
them rather than build a new object for every instance. This may save both 
time and memory, but is otherwise irrelevant.

Something similar is done for strings:

>>> a = "hello"
>>> b = "hello"
>>> a is b
True
>>> a = "hello, world"
>>> b = "hello, world"
>>> a is b
False

But:

>>> a = "hello, world"; b = "hello, world"
>>> a is b
True

Again this is an optimization (mostly targeted at attribute names) which 
should not affect the behaviour of a properly written Python program.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Antoon Pardon]

On 02/03/2016 09:32, Salvatore DI DIO wrote:
> Hello,
>
> I know Python does not have variables, but names.
> Multiple names cant then be bound to the same objects.
>
> So this behavior 

Python has variables. They are just not the kind of variables
you find in C and variations but more like variables in lisp,
scheme and smalltalk.
 

 b = 234
 v = 234
 b is v
> True
>
> according to the above that is ok

No that is just a coincidence. A consequent of the particular
implimentation, that has prepared a number of number objects
beforehand. There is no guarantee in the language that the
third statement above will produce True.

> But where is the consistency ? if I try :
>
 v = 890
 w = 890
 v is w
> False
>
> It is a little difficult to explain this behavior to a newcommer in Python.

This behaviour is undefined in the language. So there is nothing to explain
except that it depends on implementation details. Any program that depends
on two variable being the same or not the after similar code is wrong.

-- 
Antoon Pardon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explaining names vs variables in Python

[Jesper K Brogaard]

Den 02-03-2016 kl. 09:32 skrev Salvatore DI DIO:

Hello,

I know Python does not have variables, but names.
Multiple names cant then be bound to the same objects.

So this behavior


b = 234
v = 234
b is v

True

according to the above that is ok



But where is the consistency ? if I try :


v = 890
w = 890
v is w

False

It is a little difficult to explain this behavior to a newcommer in Python

Can someone give me the right argument to expose ?

Regards



You may get an answer to your question here: 
http://stackoverflow.com/questions/2419701/python-object-identity-question


As I understand it, when you use 'is', you are comparing addresses to 
objects, not the values contained in the objects. Use '==' instead.


Take a look here as well: 
https://docs.python.org/3.5/reference/datamodel.html


--
Venlig hilsen / Best regards
Jesper K. Brogaard

(remove upper case letters in my e-mail address)
--
https://mail.python.org/mailman/listinfo/python-list

Explaining names vs variables in Python

[Salvatore DI DIO]

Hello,

I know Python does not have variables, but names.
Multiple names cant then be bound to the same objects.

So this behavior 

>>> b = 234
>>> v = 234
>>> b is v
True

according to the above that is ok



But where is the consistency ? if I try :

>>> v = 890
>>> w = 890
>>> v is w
False

It is a little difficult to explain this behavior to a newcommer in Python

Can someone give me the right argument to expose ?

Regards

-- 
https://mail.python.org/mailman/listinfo/python-list