Re: Code to Joy in The Economist (June/July 2018)

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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>> >> [email protected]
>> >> 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
>> > [email protected]
>> > 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
[email protected]
https://mail.python.org/mailman/listinfo/edu-sig