Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103846 > unrolled thread

Explaining names vs variables in Python

Back to article view | Back to comp.lang.python

Contents

  Explaining  names  vs variables  in Python Salvatore DI DIO <salvatore.didio@gmail.com> - 2016-03-02 00:32 -0800
    Re: Explaining names vs variables in Python Jesper K Brogaard <jesper@brogAAaard.eu> - 2016-03-02 10:03 +0100
      Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-02 21:32 +1100
        Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 14:34 +0200
          Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-02 23:50 +1100
            Re: Explaining names vs variables in Python Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-02 15:11 +0200
            Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 15:39 +0200
              Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-03 00:48 +1100
                Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 16:11 +0200
                  Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-02 07:08 -0800
                  Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 04:23 +1100
                    Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-02 09:28 -0800
                    Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 20:12 +0200
                      Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 12:52 +1100
                        Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-03 09:03 -0800
                          Re: Explaining names vs variables in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-03 12:53 -0700
                    Re: Explaining names vs variables in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-02 21:49 +0000
                      Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 13:05 +1100
                        Re: Explaining names vs variables in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-03 16:09 +0000
                    Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-03 08:52 +1100
                      Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-02 17:23 -0800
                    Re: Explaining names vs variables in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-02 22:51 +0000
                Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 04:10 +1100
    Re: Explaining names vs variables in Python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-02 10:08 +0100
    Effects of caching frequently used objects, was Re: Explaining  names  vs variables  in Python Peter Otten <__peter__@web.de> - 2016-03-02 10:12 +0100
    Re: Explaining  names  vs variables  in Python Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-02 11:35 +0200
      Re: Explaining names vs variables in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-02 08:13 -0700
        Re: Explaining names vs variables in Python Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-02 17:37 +0200
    Re: Explaining  names  vs variables  in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-02 21:16 +1100
    Re: Explaining  names  vs variables  in Python "ast" <nomail@invalid.com> - 2016-03-02 11:52 +0100
      Re: Explaining  names  vs variables  in Python Salvatore DI DIO <salvatore.didio@gmail.com> - 2016-03-02 02:58 -0800
    Re: Effects of caching frequently used objects, was Re: Explaining  names  vs variables  in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-02 09:16 -0500
    Re: Explaining  names  vs variables  in Python Ben Finney <ben+python@benfinney.id.au> - 2016-03-03 04:53 +1100
    RE: Effects of caching frequently used objects, was Re: Explaining names  vs variables  in Python Albert-Jan Roskam <sjeik_appie@hotmail.com> - 2016-03-25 13:03 +0000
    Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-26 00:22 +1100
    Re: Effects of caching frequently used objects, was Re: Explaining names  vs variables  in Python Ethan Furman <ethan@stoneleaf.us> - 2016-03-25 09:45 -0700

Page 2 of 2 — ← Prev page 1 [2]

#103921 — 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?

[toc] | [prev] | [next] | [standalone]

#103911 — 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 <breamoreboy@yahoo.co.uk> 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

[toc] | [prev] | [next] | [standalone]

#103884 — 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 <marko@pacujo.net> wrote:
>> Chris Angelico <rosuav@gmail.com>:
>>
>>> 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

[toc] | [prev] | [next] | [standalone]

#103848 — 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

[toc] | [prev] | [next] | [standalone]

#103849 — 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.

[toc] | [prev] | [next] | [standalone]

#103851

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

[toc] | [prev] | [next] | [standalone]

#103875 — Re: Explaining names vs variables in Python

On Wed, Mar 2, 2016 at 2:35 AM, Jussi Piitulainen
<jussi.piitulainen@helsinki.fi> 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.

[toc] | [prev] | [next] | [standalone]

#103879 — 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.

[toc] | [prev] | [next] | [standalone]

#103855

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, 9999
py> c, d = 50, 9999
py> a is c  # the same object is reused for 50 each time
True
py> c is d  # new int objects are created for 9999 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

[toc] | [prev] | [next] | [standalone]

#103859

"Salvatore DI DIO" <salvatore.didio@gmail.com> a écrit dans le message de 
news:a894d5ed-d906-4ff7-a537-32bf0187e062@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/ 

[toc] | [prev] | [next] | [standalone]

#103860

Thank you very much ast and all of you. 

I better understant now

Regards

[toc] | [prev] | [next] | [standalone]

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

On Wed, 02 Mar 2016 10:12:48 +0100, Peter Otten <__peter__@web.de>
declaimed the following:


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

	It's useful for deliberately created sentinel objects.

ENDDATA = object()
...
#some thread starts that puts stuff onto a queue, and puts
#ENDDATA on the queue when it is finished

while True:
	data = q.get()
	if data is ENDDATA: break
	#do stuff

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#103889

Salvatore DI DIO <salvatore.didio@gmail.com> 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 <URL: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

[toc] | [prev] | [next] | [standalone]

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

> To: python-list@python.org
> From: __peter__@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

 		 	   		  

[toc] | [prev] | [next] | [standalone]

#105688 — 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
<sjeik_appie@hotmail.com> 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

[toc] | [prev] | [next] | [standalone]

#105694 — 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~

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web