On Mon, Mar 28, 2011 at 3:23 PM, Michael H. Goldwasser <goldw...@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 >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
