Re: [Edu-sig] Code to Joy in The Economist (June/July 2018)
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
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.urner@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
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.ceder@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.urner@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
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 <carl@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?
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.urner@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
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
On Sat, Jun 2, 2018 at 3:25 PM, Naomi Ceder <naomi.ceder@gmail.com> wrote: proselytizing). 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
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.ceder@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 <carl@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?
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.urner@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
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
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"
On Sat, Jun 2, 2018 at 3:25 PM, Naomi Ceder <naomi.ceder@gmail.com> wrote: proselytizing). possible 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
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.turner@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.ceder@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 <carl@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?
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.urner@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
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
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
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"
On Sat, Jun 2, 2018 at 3:25 PM, Naomi Ceder <naomi.ceder@gmail.com> wrote: the proselytizing). possible 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
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.ceder@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 <carl@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.ceder@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.urner@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
On Sat, Jun 2, 2018 at 1:13 PM, kirby urner <kirby.urner@gmail.com> wrote:
Name : Object :: Luggage Tags :: Suitcase
Fixing this: Names: Object :: Luggage Tags : Suitcase (a ratio of ratios, would show this way it next books in my era, as in "this is to that :: ("as") that is to this other" and so on). I appreciate the Pycon 2018 account / perspective Naomi. Glad to know Andrew was attending in person and is reaping the benefits of joining a subculture / community, not just learning a computer language [ these go together, as most but not all, science fiction writers failed to predict i.e. that computer languages create tribalism in a positive way ]. Tangential remarks: * I just discovered Pyx this morning: http://pyx.sourceforge.net/ * I've made progress using RhinoScript (rs) a Python module compatible with 2.7 that runs inside a CAD system (proprietary, not unlike ESRI Arc* in that regard). * compiling PostGIS version of postgesql on old OSX Yosemite fails in the homebrew recipe, after about 5 hours doing OK. More in blogs happy to yak off-list. Kirby Kirby Kirby
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
(a ratio of ratios, would show this way it next books in my era
[sic] textbooks e.g. dog : wolf :: cat : tiger (opinions may vary) Final remark: examples of my 'rear view mirror' Jupyter Notebooks used during recent meet-up (#10 of a 10x 4-hour on-line Python course): https://github.com/4dsolutions/Python5/blob/master/PySummary1.ipynb https://github.com/4dsolutions/Python5/blob/master/PySummary2.ipynb https://github.com/4dsolutions/Python5/blob/master/PySummary3.ipynb These try to pack in a lot of what we covered. In retrospect, I gave the keyword 'nonlocal' short shrift and need to address this more completely in future editions. Kirby
Kirby, Thank you for your kind words. Andrew has just signed a book deal to be delivered in about a year's time. His task: to write about what it's like to learn to code. We're regularly in touch via email, he's "up for it" (as we say in Britain) and sponge-like in his desire to learn about coding, Python and the culture that surrounds it. He's also looking at other languages too (perhaps C/C++). My hope is he'll demolish some of the toxic and exclusory stereotypes and behaviours associated with coding. I hope he'll celebrate some of the progress we, in the Python community, have worked so hard to bring about in this respect. I hope he'll hold us to account as "the fifth estate", as he calls us in the Economist piece. He gets that coding is both moral and political in nature. He's clever, funny and writes extraordinarily clear and witty prose. He tells a great story too (I've read both his other books). I'm looking forward to reading what he has to say. Best wishes, N. On 02/06/18 21:13, kirby urner 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
participants (5)
-
Carl Karsten -
kirby urner -
Naomi Ceder -
Nicholas H.Tollervey -
Wes Turner