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
