[Edu-sig] looking for explanations... globals dynamic dict

[kirby urner]

On Mon, Mar 28, 2011 at 3:23 PM, Michael H. Goldwasser <goldwamh at slu.edu>wrote:

>
>
> Note well that the issue has changed since the original post.  The
> question at the time concerned the following code
>
>
Not to quibble, but the issue of the *original* post had to do with
assignments (such as those below) dynamically mutating an
"environment dict" named globals().

What this function returns varies moment to moment as a side
effect of new assignment operations top level, or deletions.

dir(), on the other hand, returns a snapshot, a "static" list
(not that lists are static in the sense of immutable -- not
what I meant).

One could imagine a globals() that *did* return a snapshot,
as dict(globals()) does.

>>> g = dict(globals())
>>> for k,v in g.items(): print(k,v, sep=":")  # no problemo

__builtins__:<module 'builtins' (built-in)>
__name__:__main__
__doc__:None
__package__:None



 >>> a = 1
> >>> b = a  # b and a are two different 1s
>
> Carl correctly points out that b and a are not two different 1s in
> this case. The assignment statment of a = b has the same semantics for
> integers as it does for any other data type.  a and b become aliases
> for the same underlying instance.  On any platform, it will be the
> case that
>
> >>> a is b
> True
>
> folowing that assignment.


Very true and related to Python's bias against unnecessary
copying, making copy (as a verb) live inside its own module
(like in a dog house) not even present as a built-in.

This is because names are light and airy whereas the objects
they name on the heap may be gargantuan, in terms of
resources used.

green = Giant( ); red = green should not inadvertently
cause two instances of Giant, with copying a side effect
of assignment.

As a language, Python is refreshingly consistent about
not doing that.


> The original misunderstanding involved the
> semantics of b += 2; that command does not mutate the underlying
> instance, but re-associates the identifier b to a new value (while a
> remains associated with the value 1).
>

Likewise I get students talking about how "hello world".upper( )
is "transforming" a string, whereas more accurately its
returning a new string instance that's based on "hello world"
-- like transcribing DNA, building a protein.

So is "transcribing" to go back to inadvertent copying?

No, because a = "hello world"; b = a.upper( ) is about
creating two different strings, each with its own name.

No copies here.


>
> In your reply, the code fragment (below) shows a different issue
> regarding the re-use of integer literals in source code (as you
> assigned b=1 rather than b=a).  In that case, it is system-dependent
> whether the interpretter uses different instances or the same
> instance, and you are right that there is no guarantee that equivalent
> instances will be identical instances.
>

>>> (17 + 1) is 18
True

>>> 8243985209384708709180298734 is (8243985209384708709180298733 + 1)
False

Implementation details...

Kirby


>
> With regard,
> Michael
>
> >
> >    Python 2.6.6
> >    Type "help", "copyright", "credits" or "license" for more information.
> >    >>> w = 1
> >    >>> y = 1
> >    >>> w is y  # this might surprise you
> >    True
> >
> >    [PyPy 1.4.1]
> >    Type "help", "copyright", "credits" or "license" for more information.
> >
> >    >>>> w = 1
> >    >>>> y = 1
> >    >>>> w is y # or are you so used to CPython that this surprises you?
> >    False
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20110328/369fc236/attachment.html>