Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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 http://nedbatchelder.com/text/names.html> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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)
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
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
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
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
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
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
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
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
