[Edu-sig] Code to Joy in The Economist (June/July 2018)

[kirby urner]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20180602/86ca38d8/attachment.html>