There's probably a notebook that better demonstrates how variables (and GC: garbage collection) work in Python?
Looks like when I copied and pasted I got a weird combination of HTML and plaintext. Here's that example again with formatting stripped (by copying and pasting to a plaintext editor and then copying and pasting back: a = 1 print(id(a)) c = 2 a = b = c print(id(a)) assert id(a) == id(b) == id(c) assert a == b == c == 2 s1 = 'str1' s1_id1 = id(s1) s1 = s1 + '23' s1_id2 = id(s1) assert s1_id1 != s1_id2 On Sunday, June 3, 2018, Wes Turner <wes.tur...@gmail.com> wrote: > a = 1 > print(id(a)) > c = 2 > a = b = c > print(id(a)) > assert id(a) == id(b) == id(c) > assert a == b == c == 2 > > s1 = 'str1' > s1_id1 = id(s1) > s1 = s1 '23' > s1_id2 = id(s1) > assert s1_id1 != s1_id2 > > > On Sunday, June 3, 2018, Naomi Ceder <naomi.ce...@gmail.com> wrote: > >> As Kirby says, of course the data does go somewhere, and that "somewhere" >> could be thought of as a container. But "creating" a variable name in >> Python doesn't in itself create a container. A lot of beginners will >> assume that: >> a = 1 >> a = b = c >> will actually create three objects, (or containers, or buckets). This >> leads to a flawed mental model of what Python actually does, with >> unexpected results for mutable types. >> >> Cheers, >> Naomi >> >> On Sun, 3 Jun 2018 at 13:56, Carl Karsten <c...@nextdayvideo.com> wrote: >> >>> > But you are totally right, Kirby - we've got to get him off of this >>> notion of variables as containers. "Post-its, not buckets" is the way I put >>> it, but I rather like the luggage tag metaphor as well. >>> >>> You lost me here. What's wrong with bucket? >>> >>> >>> On Sat, Jun 2, 2018 at 3:25 PM, Naomi Ceder <naomi.ce...@gmail.com> >>> wrote: >>> > It is a lovely article. Andrew Smith was at PyCon and I had dinner >>> with him >>> > and Nicholas one evening and also sat down and chatted with Andrew on a >>> > couple of other occasions. >>> > >>> > He's a smart guy and a likable one, and he is very taken with coding in >>> > general, Python in particular, and especially the Python community, >>> and he >>> > plans to keep going beyond just that article. I fully expect we'll see >>> and >>> > hear more of Andrew Smith's adventures with Python over the coming >>> year or >>> > two. >>> > >>> > But you are totally right, Kirby - we've got to get him off of this >>> notion >>> > of variables as containers. "Post-its, not buckets" is the way I put >>> it, but >>> > I rather like the luggage tag metaphor as well. >>> > >>> > And for those of us who are geeks "of a certain age" I can also >>> recommend >>> > his book Moondust, which is the story of him tracking down and talking >>> to >>> > all of the surviving Apollo astronauts in the early 2000's. >>> > >>> > Cheers, >>> > Naomi >>> > >>> > On Sat, 2 Jun 2018 at 15:13, kirby urner <kirby.ur...@gmail.com> >>> wrote: >>> >> >>> >> >>> >> >>> >> One of my screen scraper friends (always reading) just forwarded this >>> >> link: >>> >> >>> >> https://www.1843magazine.com/features/code-to-joy >>> >> >>> >> A highly literate middle aged writer tackles programming from zero and >>> >> winds up in Python after a pilgrimmage through Javascript, and uses >>> the >>> >> Twitter API. He meditates on what learning to code might mean to a >>> fully >>> >> developed adult such as himself (connects to Andragogy **). >>> >> >>> >> Nicholas Tollervey, sometime edu-sig poster and Micro:bit avatar, is >>> very >>> >> much a hero in this story, living up to the ideal of a Pythonista as >>> >> >>> >> (A) not religiously dogmatic (re "language wars") yet >>> >> (B) having enthusiasm for sharing Python (without too much >>> proselytizing). >>> >> >>> >> Bravo on a stellar performance! >>> >> >>> >> Quincy Larson of freeCodeCamp fame is another champion of openness and >>> >> accessibility (and good advice). I get his emails in my inbox with >>> >> gratitude, though I don't follow all the links (helpfully labeled with >>> >> estimated reading times, for my internal scheduler -- thanks for the >>> >> meta-data!). >>> >> >>> >> In the interests of sparking some edu-sig type discussion (this could >>> fork >>> >> to a new thread), the author Andrew Smith writes: >>> >> >>> >> "Variables are best (if imperfectly) understood as the vessels within >>> >> which pieces of data are contained, ready to be worked on. Of many >>> possible >>> >> data types, the most straightforward are numbers and strings, string >>> being >>> >> the name given to text." >>> >> >>> >> In my classes I readily acknowledge the "variable as container" >>> metaphor >>> >> is apt, and agree that Python objects take up memory and so object == >>> >> container (with id) is OK too. >>> >> >>> >> However, the name --> object mapping of a namespace is better >>> imagined as >>> >> "luggage tag -> suitcase" relationship. It's not like the Python name >>> itself >>> >> is the container on the heap. >>> >> >>> >> The object in memory is a possibly fat heavy suitcase, stuffed with >>> stuff >>> >> (e.g. an HttpResponse). However the name is more a label, like a >>> luggage >>> >> tag on a suitcase (and this is the point). >>> >> >>> >> Name : Object :: Luggage Tags :: Suitcase >>> >> >>> >> One suitcase (object) may have many names (connects to garbage >>> collection >>> >> discussion). However at any one moment, a name points to only one >>> object >>> >> (the same name in different modules, both running, still count as >>> different >>> >> names -- scope matters). >>> >> >>> >> So yeah, the object itself is a "container" but what it contains may >>> be >>> >> tags to other objects. >>> >> >>> >> Without this separation of "names" from "objects" there's an >>> inevitable >>> >> tendency to imagine copies, as how can we have two bowls or boxes with >>> >> exactly the same content. >>> >> >>> >> We don't have a visual metaphor for "two suitcases containing exactly >>> the >>> >> same clothes at the same time". >>> >> >>> >> But we do understand "one suitcase having two or more luggage tags." >>> >> >>> >> Surely we have two copies, albeit clones of the same thing. Not so in >>> >> Python though. Python is biased against making gratuitous copies of >>> >> anything. Keep is spare! (sparse if possible). Don't clutter memory >>> with >>> >> excessive redundancy. >>> >> >>> >> >>> >> Kirby >>> >> >>> >> ** >>> >> http://4dsolutions.net/presentations/pycon2013.pdf >>> >> >>> >> >>> >> _______________________________________________ >>> >> Edu-sig mailing list >>> >> Edu-sig@python.org >>> >> https://mail.python.org/mailman/listinfo/edu-sig >>> > >>> > >>> > >>> > -- >>> > Naomi Ceder >>> > >>> > @NaomiCeder • https://www.linkedin.com/in/naomiceder/ >>> > https://www.manning.com/books/the-quick-python-book-third-edition >>> > >>> > _______________________________________________ >>> > Edu-sig mailing list >>> > Edu-sig@python.org >>> > https://mail.python.org/mailman/listinfo/edu-sig >>> > >>> >> >> >> -- >> Naomi Ceder >> >> @NaomiCeder • https://www.linkedin.com/in/naomiceder/ >> https://www.manning.com/books/the-quick-python-book-third-edition >> >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
