Re: Clarification on Immutability please
Am 21.01.2020 19:38 schrieb Chris Angelico: On Wed, Jan 22, 2020 at 4:42 AM Stephen Tucker wrote: and even that the first id(mytup) returns the same address as the second one, I am left wondering exactly what immutability is. Let's look at id()'s documentation: id(object) Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value. Are you sure that it does? I can't reproduce this. When you slice the first two from a tuple, you create a new tuple, and until the assignment happens, both the new one and the original coexist, which means they MUST have unique IDs. I'd expect that, too, but an "atomic" reassignment would not contradict the documentation. Somehow, it seems, tuples can be reduced in length (from the far end) (which is not what I was expecting), but they cannot be extended (which I can understand). Different ID means different object, but identical ID doesn't mean identical object. The Python implementation allows re-use of an object's ID after the object has been destroyed, and the documentation mentions this explicitly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Sandboxing eval() (was: Calculator)
Thanks, Chris (and others), for the comprehensive answer (as usual). I got interesting insights into Python's inner workings. Of course, when everything is an object, everything has parents and other relatives, so by traversing that tree in the right way one can make one's way all the way to the core. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clarification on Immutability please
On Tue, Jan 28, 2020 at 1:13 AM Musbur wrote: > > Am 21.01.2020 19:38 schrieb Chris Angelico: > > Are you sure that it does? I can't reproduce this. When you slice the > > first two from a tuple, you create a new tuple, and until the > > assignment happens, both the new one and the original coexist, which > > means they MUST have unique IDs. > > I'd expect that, too, but an "atomic" reassignment would not contradict > the documentation. The way execution works in Python, you first evaluate the object, then assign it to the target. The new object HAS to exist before the old one is replaced. There's no such thing as "atomic reassignment" that simultaneously destroys the old object and assigns a new one. The slicing will always happen first, and then the assignment. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Clarification on Immutability please
On Tue, Jan 28, 2020 at 2:44 AM Souvik Dutta wrote: > > If the two objects have the same value that means that when called all of > them will point to the same object rather than creating the same value - > object pairs twice. Immutability is the characteristics that does not let you > change the value once set. Example - a = 5 > b = 5 > Then when a and b are called rather than saving two different objects with > the same value python just creates one value and then let's two or more > objects to point to the same value. > (I'm going to assume you meant that for the list rather than a personal email.) If you have two independent constants that happen to have the same value, the compiler is free to share them, but it's not required to. Current versions of CPython do share small integers and some strings, but not all - if you used, say, 500 instead of 5, they would quite possibly be distinct objects. Other Python interpreters are free to have different optimization rules. For instance, it's absolutely legit to intern every string on creation, thus guaranteeing that any two equal strings will be the same object; I don't know of any interpreter that does this, but it's completely legal according to the specification. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 196, Issue 26
On 1/27/20 12:03 AM, אורי wrote: > Please don't reply to digest. Replying to a digest is just fine. Just make sure to change the subject line in the future so people know what it's referring to. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python-list Digest, Vol 196, Issue 26
On 28/01/20 5:17 AM, Michael Torrie wrote: On 1/27/20 12:03 AM, אורי wrote: Please don't reply to digest. Replying to a digest is just fine. Just make sure to change the subject line in the future so people know what it's referring to. Excepting that whilst this practice (subject to faithful reproduction) eases 'visual indexing', it still breaks the "threading" of email conversations (for those of us wot use it on our local machines AND in the archives). -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
