That doesn't tell me how postit notes are different from buckets. I get the python side, I don't get how the analogies are different.
I am also not sure the target audience comes to the conclusions about implementation you all seem worried about. Hmm, implementation may not be the right word, I think that's not abstract enough. If you are talking to a seasoned C programmer that understands what "int a" does, then sure, tell him how Python is different. If you are talking to someone who wants to use Dreamweaver to edit code, I am sceptical that spending time on this is a good idea. One of the biggest problems I have at Office Hours is spending so much time talking about tangents that we run out of time to finish the original topic. I somewhat expect that the tangents are equally helpful, so I am not too worried about it. But if you are working up a curriculum or lesson plan or whatever, I question what things should be included. On Sun, Jun 3, 2018 at 8:50 AM, 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
