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
Responding to the most recent by Wes...
Excellent & Comprehensive. Thanks for bringing sys.refcount to the table.
I think newcomers sometimes grow in confidence when they get these peeks
into back stage behind-the-scenes stuff.
As long as we express it clearly, we're putting folks on a fast track to
becoming "insiders".
> # We usually don't ``del(variable)`` in Python because the garbage
> collector will free that memory anyway whenever it happens to run and the
> refcount is zero because the variable has fallen out of scope.
> #
>
A tiny point:
del variable
is slightly more correct than
del(variable)
following the rule that "no keyword is a callable".
You have it right in your dialog with the interpreter.
Remembering that rule saves people treating if and return as callables as
well, which I consider an "accent".
if(condition):
return(object)
Still works. You see this when students are coming from other languages.
Just the parens aren't doing anything.
>>> import keyword
>>> keyword.kwlist
A list of not-callable names.
> # In practice, we name global variables in ``ALL_CAPS`` (and may expect
> them to be constants). We wrap 'private' variable names with dunder
> (``__variable__``) so that other code can't modify those object attributes
> (due to 'name mangling').
>
I believe best practice is to put the double-underlines only on the left
e.g. hidden = __variable
The two underlines on the left side are sufficient to provoke name mangling.
The rule here is: Python provides us with the special names ( __ribs__ );
we don't create them.
> Sometimes, we name variables with a single ``_underscore`` in order to
> avoid a 'variable name collision' with outer scopes (or to indicate, by
> convention, that a variable is a local variable)
> #
>
Yes. I tell people the _semi_private names are not guaranteed to stay the
same from version to version i.e. the coder is telling the code reader "use
this at your own risk, I'm not guaranteeing it'll still be there later".
I.e. _semi_private names are not part of the official API, are
specifically excluded therefrom.
Often used for method names internal to classes.
The same goes for __super_private, only more so.
> # In practice, we try to avoid using globals because when or if we try to
> add threads (or port to C/C++), we're never quite sure whether one thread
> has modified that global; that's called a *race condition*. Some languages
> -- particularly functional languages like Haskell and Erlang -- only have
> mostly all immutable variables; which avoids race conditions (and the
> necessary variable locking that's slowing down Python GIL removal efforts).
>
Yes, in practice best to have globals be immutable type objects, not a
place to store state.
I think of the django settings.py and other such config files as places to
store framework-wide globals.
> #
> # Is it a box or a bucket?
> # It's a smart pointer to an allocated section of RAM.
> #
>
The allocated section of RAM is the box or bucket.
Names and Objects are distinct.
Names (pointers) go to the left of the assignment operator, Objects
(containers) to the right of same.
> # When do we get a new box and throw an old one away? Is there a name for
> the box and the thing in the bucket? Does the bucket change size when?
> #
>
Bucket = Box = Object (on the heap).
Name = Post-it = Label = Tag
https://flic.kr/p/DQb8t6
Names must take up a little bit of memory too. Very long names take up a
little more.
> # I think the box/bucket metaphor is confusing and limiting; but I've been
> doing this for a long time: it's a leaky abstraction.
> #
> # - https://en.wikipedia.org/wiki/Memory_leak
> # - https://en.wikipedia.org/wiki/Race_condition
> # - https://en.wikipedia.org/wiki/Smart_pointer
>
>
Lets not forget weakref -- worth bringing in right when we're talking
about garbage collection and reference counts.
https://docs.python.org/3/library/weakref.html
Kirby
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" <carl(a)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.ceder(a)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(a)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(a)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(a)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(a)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(a)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(a)python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
