Is the box more like a bucket or a postit? ;)
I'd like to point out that an answer to my question should include the
words bucket and post-it.
but hey, if someone wants to dig up the cpython source code that shows
what memory is used for A=1, I'll read that too.
On Sun, Jun 3, 2018 at 12:30 PM, Eric Matthes <ehmatt...@gmail.com> wrote:
> I think the key here is to start with an accurate metaphor, that you can
> build upon later. Consider this brief introduction to variables:
>
> "A variable is like a label on a piece of data. That piece of data can be
> simple, such as a number or a name, or it can be a more complex data
> structure. Whenever you want to work with that data, you can just use the
> name of the variable instead."
>
> Compare that phrasing to this one:
>
> "A variable is like a box, which you can put a piece of data in. That piece
> of data can be simple, such as a number or a name, or it can be a more
> complex data structure. Whenever you want to work with that data, you can
> just use the name of the variable instead."
>
> You can move right from either of these phrases into examples using
> variables. But when you get to the point where you're focusing on "debugging
> reference/ value mix ups", one of these introductions serves you much
> better. The first allows you to jump right into clear explanations of how to
> consider what's happening in your program. The second requires you to go
> back on your original explanation, reintroduce the variable concept, and
> then move forward.
>
> I started teaching and writing using the "value in a box" model because
> that's what I was taught. But I have recently switched my teaching and
> writing over to use the "label on a piece of data" model, because it's more
> accurate for Python.
>
> Eric
>
> On Sun, Jun 3, 2018 at 9:00 AM, Carl Karsten <c...@nextdayvideo.com> wrote:
>>
>> Not only does that not answer my question, it contradicts previous
>> statements.
>>
>> >> >> You lost me here. What's wrong with bucket?
>>
>> >> That doesn't tell me how postit notes are different from buckets.
>>
>> and, I assure you, even if one (me) understands all that fish in
>> bucket stuff, I still experience frustration debugging reference/value
>> mix ups.
>>
>> So I totally disagree with "must teach them this" assertion. Every
>> minute spent on that displaces time that could be spent on something
>> else, and I think you will saturate someones attention long before you
>> run out of better things to teach.
>>
>>
>> On Sun, Jun 3, 2018 at 11:29 AM, David Handy <da...@handysoftware.com>
>> wrote:
>> > If you have two buckets, bucket A and bucket B, and you put a fish into
>> > bucket A, a fish does not magically appear in bucket B also.
>> >
>> >>>> bucket_a = []
>> >>>> bucket_b = []
>> >>>> bucket_a.append('fish')
>> >>>> bucket_b
>> > []
>> >
>> > But, if you have only one bucket with two labels on it, bucket A and
>> > bucket B, then when you use label A to put a fish into the bucket, and then
>> > use label B to look at the bucket, you will see that same fish.
>> >
>> >>>> bucket_a = []
>> >>>> bucket_b = bucket_a
>> >>>> bucket_a.append('fish')
>> >>>> bucket_b
>> > ['fish']
>> >
>> > This is a crucial conceptual understanding our students must gain or
>> > they will experience endless frustration trying to debug their programs,
>> > not
>> > understanding the behavior. Whether they use DreamWeaver or some other
>> > editor, this is relevant.
>> >
>> > David H
>> >
>> >
>> > On Sunday, June 3, 2018 11:39am, "Carl Karsten" <c...@nextdayvideo.com>
>> > said:
>> >
>> >
>> >
>> >> 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
>> >>
>> >
>> >
>> >
>> > _______________________________________________
>> > Edu-sig mailing list
>> > Edu-sig@python.org
>> > https://mail.python.org/mailman/listinfo/edu-sig
>> _______________________________________________
>> Edu-sig mailing list
>> Edu-sig@python.org
>> https://mail.python.org/mailman/listinfo/edu-sig
>
>
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig
