From kirby.urner at gmail.com  Tue Feb  2 04:28:55 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 2 Feb 2016 01:28:55 -0800
Subject: [Edu-sig] what is ~fluent Python?
Message-ID: <CAPJgG3QOr_=z4NxL=ORpDco8_RGfNUneOsPYUY=WDpzRmiPiWw@mail.gmail.com>

Nobody wants to admit to not having some command of a language, just people
need to use languages to different levels, human as well as computer
(language).

In saying "workaday" or "everyday" Python I suppose I'm circling the word
"mundane"?

We remember that Scheme (PLT version in particular) came with "levels" i.e.
one could actually set a global that predetermined which features would be
usable.

In Python we might imagine, but never had:
from __level1__ import *

That's more just a figure of speech anyway.

Here's what our head instructor considers "yellow belt Python" (like first
level from none):


The outline of what she wants covered (with my additions in red for the
accelerated course) is:

The concepts the core programming concepts students are expected to know
> and be comfortable with on completion of the intro course are:
>
*-* variables
> *- *strings (*ascii vs. unicode*)
> *- *(*bytes*)
>
*-* ints (*floats, Decimal, Fraction*)
> *- *basic string concatenation (*str.format method*)
> - basic int math
> - *datetime and calendar math*
>
- Boolean conditionals
> - what a loop is
>
> Students should have exposure to and some practice with, in order of
> familiarity:
> - if/elif/else
> - while loops
> - for loops
> *- *functions
> - Lists (*tuples*, *namedtuples*)
> - Dictionaries (*sets*)
> - Classes
>

This 45 minute Youtube, Python in 45 Minutes, covers about everything
covered in the Intro Class:

http://mybizmo.blogspot.com/2016/01/code-school-syllabus.html  (my blogged
review)

I've added in red-bold what I consider to distinguish the "accelerated"
class I'm teaching versus their conventional Intro course (they decided to
do something more experimental in my case -- good show of flexibility).
However in the edu-sig archives that coding won't be in the default view.
No big deal.

Missing from the above?

Quite a lot of course, starting with generators and decorators.  Also
missing completely is file i/o, which we have to add (the outline was just
a back of the napkin thing, nothing hard-coded, open to suggestions...).
The point is to set levels, i.e. expectations.  I think a lot of teachers
would drop out classes whereas our guidelines say to get there, but not
right away (I tend to jump the gun).

I think namedtuples are especially good at bridging the gap from a
primitive tuple, which we all understand (some "we" that applies), to an
object that accepts dot notation.  With namedtuple P = namedtuple('Point',
'a b c d') one may have p = P(1, 0, 0, 0) and get p.a and p.b, as well as
string 'Point' in the __repr__.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160202/bf1f0fe5/attachment.html>

From kirby.urner at gmail.com  Tue Feb  2 13:15:14 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 2 Feb 2016 10:15:14 -0800
Subject: [Edu-sig] what is ~fluent Python?
In-Reply-To: <CANMY=3NX+732-ShZn-7nRk66B-vLQ3vyPBzZvLokN5aTO=+b5w@mail.gmail.com>
References: <CAPJgG3QOr_=z4NxL=ORpDco8_RGfNUneOsPYUY=WDpzRmiPiWw@mail.gmail.com>
 <CANMY=3NX+732-ShZn-7nRk66B-vLQ3vyPBzZvLokN5aTO=+b5w@mail.gmail.com>
Message-ID: <CAPJgG3Ry-JK27618xUx6DPNkSjk2cA4NE8KDK8Lff6aTv_VQDQ@mail.gmail.com>

On Tue, Feb 2, 2016 at 6:24 AM, Juliano <julianofischer at gmail.com> wrote:

> Hello, everybody!
>
> Taking advantage of the semantic redundancy =)
>
> It is common for Python programmers try to adapt Python to patterns
> learned in other languages. This can prevent them from learning powerful
> features available in the Python language.
>
> There is a very good book, called Fluent Python, written by  Brazilian
> Luciano Ramalho, which addresses these issues.
>
>
Yes, totally a good book, I've been studying it quite a bit!
I second your opinion.

I used a tilde ~ to mean something like "not fluent" or
"the opposite of fluent" but that was maybe too cryptic.

What comes up for code school / night school teachers
like me is who to package Python-the-language into
learnable chunks.

I'm thinking of going with a martial arts schema where
one has "belts" of different color:

http://www.wmacenter.com/index.cfm?page=17

So what would that look like?  I'm thinking maybe
something like:

White Belt:  using Python as a calculator.  Naming objects for later use.
print("Hello World")

Yellow Belt:  installing Python, using an IDE.  str, int, if / elif / else;
loops
Some understanding of big picture use of __ribs__ (special names)
Writing functions, a reading knowledge of classes.  Some file i/o.

Orange:  generator functions and expressions, itertools and iter( )
Designing / writing classes.  Overloading such as __getitem__
or __setattr__  Full understanding of __call__ API i.e. **dict and
*sequence parameters.

Green:  decorators, context managers, descriptors, properties,
class and static methods using decorator syntax, better understanding
of MRO (method resolution order).

[ skipping Blue and Purple but adding more from collections module and
other standard library goodies ]

Brown:  numpy, pandas, web frameworks, more awareness of 3rd party
world, metaclasses

Black:  event loops, threading, multi-processing, concurrency, extending
Python in other languages (e.g. C)

Note that "Black" does not connote high level mastery so much as a
complete understanding with experience.   I.E. black belt = what's in
Fluent Python (the book).

To quote that martial arts site above:

Another common misbelief that needs to be clarified is the "black belt
as master" stereotype,. In reality, a black belt indicates the wearer
is competent in a style's basic technique....  and them come several
levels of "Black".

Kirby





>
> Juliano Fischer Naves
> Informatics Professor  - IFRO
> D.Sc. Student - IC/UFF/Brazil
>
<https://mail.python.org/mailman/listinfo/edu-sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160202/2f2df3ce/attachment.html>

From kirby.urner at gmail.com  Tue Feb  2 14:55:30 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 2 Feb 2016 11:55:30 -0800
Subject: [Edu-sig] what is ~fluent Python?
In-Reply-To: <CANMY=3OnKnLr6x+Aww41zyJMNOBQhB5WdHhbW9HU7ALkZ=W5mA@mail.gmail.com>
References: <CAPJgG3QOr_=z4NxL=ORpDco8_RGfNUneOsPYUY=WDpzRmiPiWw@mail.gmail.com>
 <CANMY=3NX+732-ShZn-7nRk66B-vLQ3vyPBzZvLokN5aTO=+b5w@mail.gmail.com>
 <CAPJgG3Ry-JK27618xUx6DPNkSjk2cA4NE8KDK8Lff6aTv_VQDQ@mail.gmail.com>
 <CANMY=3OnKnLr6x+Aww41zyJMNOBQhB5WdHhbW9HU7ALkZ=W5mA@mail.gmail.com>
Message-ID: <CAPJgG3RXGxDp0O0HyjNjGWaaZ9b4gS37Dr2icJ5xA_2tGbwCmw@mail.gmail.com>

On Tue, Feb 2, 2016 at 10:45 AM, Juliano <julianofischer at gmail.com> wrote:

> Sorry Mr. Kirby, I really did not notice the tilde.
> Shame on me.
>
>
Shame on me then for being too obscure. :-D

BTW, I demonstrate overloading tilde ~ using __invert__ in px_class.py in
the Accelerated folder in here:

 http://bit.ly/1TrSJFB

(my stash of <guild /> course files)

After some hours of Orientation we needed to face the issue of
zero-to-white and yellow-to-orange belt trainees in the same room.

We quickly decided, just yesterday, after three meetups, to fork the class
and let me continue with the yellow-to-orange.  The two folders in the
above DropBox reflect this forking.  This was not actually Orientation but
pre boot camp, so those aspiring had fewer hours to prepare.  Long story.
Short version:  this is just a six meetup course (M-W-Fri 6-9 PM) and we
got a really wide mix of students (a good thing! -- that's life!).

In a typical Orientation session, you'll have people are coming from
construction, having sustained injuries and now looking for desk jobs,
learning typing on the list of things to tackle, mixed with others who have
maybe had significant experience as programmers but maybe over a decade ago
having done other things in between, so needing a refresher in more
contemporary tools.

Having this range of diversity in one classroom is interesting and my
approach was to tell a lot of stories, focus on lore, while being very
gradualist about the install hurdle, which some had crossed already, others
never.

People enjoyed this part, but we must all buckle down and learn to actually
read and write code, not just watch some instructor do it for us!

The <guild /> is famous for hands-on.  This is not music theory /
appreciation only, one must bring one's violin!  We must play notes!

I've become a big fan of PythonAnywhere.com for its nothing-to-install
environment and encouraged any student up for it to grab an account and
make me their mentor.

Now these students show up in my /home directory as co-workers and I can
slide them .py files to chew on, in a bash shell using python3.  The
web-browser GUI is fairly intuitive and provides an easy way to upload /
download.

One does need to be on Wifi / Internet however, for PythonAnywhere to work,
so *in addition* (it's not either/or) I recommend a native laptop install.
I gave them two choices:  Python.org or Anaconda.org, saying we'd be coding
in Python 3.x exclusively but would talk a lot about the differences.

Anyway, after some hours of demo, overview and fun stories, the hard
reality of:

(a) maybe not even having a laptop yet and/or
(b) feeling confused where to actually start, began to set in.

It's a whole different ballgame to do it oneself, right?  Given the
immanence of the next boot camp (coding dojo), we made the decision to fork
and have a clinic for true beginners.

This sorting out phase is normal, and in an Orientation period and gives
people a lot of freedom to make their own decisions regarding what's best
for their goals.

Some need to get to white belt first.  Others would be bored in white belt
and are chomping at the bit for higher level training.

A fellow instructor is working with that white belt group while the head
instructor (not me, I'm a noob) has explained to students how they're free
to wander back and forth as we're only a few doors apart.  Get a sense of
the next level, go back to square one.  It's an iterative process.

Tomorrow night, just to confuse them, we'll switch rooms (Accelerated
Programming will be closer to the front door, depicted below):

https://flic.kr/p/C1Ge6p

Recap of my teaching experience:

I've been teaching 100% asynchronously, not in real time, not seeing my
students, for a few years with O'Reilly, great gig.  That's finally ending
this week, as in tomorrow.

At OST, we would spin them up an "average desktop" i.e. Windows client for
a Linux server, they'd remotely pilot using RDP.  Eclipse was their IDE but
not a really up-to-date one.  Realism more than idealism was the goal.

Now I'm back to real time with two separate contracts:  this gig with
<guild /> and an "Internet radio show" teaching Python to Californians who
qualify, via saisoft.net.

I have to actually go to a dedicated building (foreign concept!) to do the
<guild /> job.  So not only do I have to think on my feet and walk around
more (gasp!), I need to contend with diverse install issues in multiple
operating systems.  Having a TA in the room (Chris) really helps.

Like I take 'em to Python.org right away, but I also show them several IDEs
such as Spyder, Pycharm, Eclipse and don't insist they all grab the same
thing (some may have already made choices).

For those least familiar with this terrain, we have fall-back choices e.g.
Atom for a text editor.  Or maybe Notepad++ for Windows users.

Here are some more pictures of the code school and its environs:

https://www.flickr.com/photos/kirbyurner/albums/72157664250599655


As I see it, your idea is very interesting.
> In fact, I am thinking about a teaching project: "Programming Python Like
> a Ninja!"
> Maybe a competition: "Ultimate Python Championship".
>
>
Yes, there's a lot of overlap in the namespaces.  Words like "coding dojo"
are common.
210K hits on Google for "coding dogo"

This makes sense, partly in terms I'm fleshing out here i.e. we can
stratify a computer
language into usable chunks each with a degree of utility.

Maybe using Python as a calculator really is just what you need.



> As a school teacher, I always consider your insights, ideas, and opinions
> very inspiring.
>
> Thank you very much, *sensei* Kirby.
>

I'm feel honored by a respected peer.    :-D

Kirby


>
> Juliano Fischer Naves
> Informatics Professor  - IFRO
> D.Sc. Student - IC/UFF/Brazil
>
> Please do not send me Microsoft Office/Apple iWork documents. Send
> OpenDocument instead! http://fsf.org/campaigns/opendocument/
> Liberate your documents!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160202/c91e4755/attachment-0001.html>

From mark.engelberg at gmail.com  Tue Feb  2 18:42:03 2016
From: mark.engelberg at gmail.com (Mark Engelberg)
Date: Tue, 2 Feb 2016 15:42:03 -0800
Subject: [Edu-sig] what is ~fluent Python?
In-Reply-To: <CAPJgG3QOr_=z4NxL=ORpDco8_RGfNUneOsPYUY=WDpzRmiPiWw@mail.gmail.com>
References: <CAPJgG3QOr_=z4NxL=ORpDco8_RGfNUneOsPYUY=WDpzRmiPiWw@mail.gmail.com>
Message-ID: <CAORbMOOVm7yHTneDA=igBbSk95hB=pz-7ee4Wouqd2=7aG47Lg@mail.gmail.com>

On Tue, Feb 2, 2016 at 1:28 AM, kirby urner <kirby.urner at gmail.com> wrote:

>
> We remember that Scheme (PLT version in particular) came with "levels"
> i.e. one could actually set a global that predetermined which features
> would be usable.
>

In PLT, the notion of levels is primarily about giving meaningful error
messages.  (cons 1 2) is meaningful in full Racket, but for a beginner,
this is almost certainly an error.  All of the language levels, even the
so-called "advanced student language", are very minimalist in terms of
their feature sets, and there are really good reasons to teach programming
using a restricted set of language constructs.

My biggest concern about your Python "belt" system is that you present it
as a kind of checklist that students should strive to understand on their
way to mastering the language.  But most of the things on your list are
language features, not deep concepts, and I see that as a problem.  For
example, in PLT, I can take a student who knows only Intermediate Level
constructs (https://docs.racket-lang.org/htdp-langs/intermediate-lam.html),
and spend two years teaching him or her deeper and deeper problem solving
techniques, without ever introducing a single new language feature.  This
is where one's true strength as a programmer is derived.

I find it interesting that your subject line talks about "fluency", because
there's an analogy here to studying foreign language that you seem to have
missed.  In my experience, fluency has very little to do with how much
vocabulary you know.  When I study a foreign language, I'm pretty good at
memorizing new words.  But then I routinely meet people who know far fewer
words than I, yet are far more fluent, because they are better at using the
words they know to talk about whatever they wish, while I spend a
noticeable amount of time searching my brain for just the right word.
Going with that analogy, your belt list comes across as a series of
"vocabulary lists", but memorizing all that vocab isn't what's going to
make you fluent.  Better to learn how to express yourself with a restricted
vocabulary, better to learn how to think in the foreign language.

The PLT "list of things to master" would start out with things like:
writing functions to operate on atomic data, writing functions to operate
on structured data, writing functions to operate on collections,
understanding structural recursion, understanding generative recursion,
learning how to write well-tested code, etc.  Where are these things on
your list?

So, I encourage you to rethink your belt system in terms of concepts, in
terms of thinking and problem solving, in terms of fluency as it is defined
in foreign languages.  See
http://www.ccs.neu.edu/home/matthias/Thoughts/Growing_a_Programmer.html for
more ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160202/ec270812/attachment.html>

From kirby.urner at gmail.com  Tue Feb  2 23:39:56 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 2 Feb 2016 20:39:56 -0800
Subject: [Edu-sig] what is ~fluent Python?
In-Reply-To: <CAORbMOOVm7yHTneDA=igBbSk95hB=pz-7ee4Wouqd2=7aG47Lg@mail.gmail.com>
References: <CAPJgG3QOr_=z4NxL=ORpDco8_RGfNUneOsPYUY=WDpzRmiPiWw@mail.gmail.com>
 <CAORbMOOVm7yHTneDA=igBbSk95hB=pz-7ee4Wouqd2=7aG47Lg@mail.gmail.com>
Message-ID: <CAPJgG3RUZv3032MHMrtRf_yVueKgR+8FfcEmrmLayh7G4-fOng@mail.gmail.com>

On Tue, Feb 2, 2016 at 3:42 PM, Mark Engelberg <mark.engelberg at gmail.com>
wrote:

< ... >


> So, I encourage you to rethink your belt system in terms of concepts, in
> terms of thinking and problem solving, in terms of fluency as it is defined
> in foreign languages.  See
> http://www.ccs.neu.edu/home/matthias/Thoughts/Growing_a_Programmer.html
> for more ideas.
>

Yes, I'm finding a wealth of good materials here, much to ponder.

What I'm finding with my California class, where I have 40 hours to cover
Python, including Labs, is that I'm taking the same bonehead approach I'm
using with <guild /> and sorting the keywords into rough levels, color
coded e.g. 'yield' and 'try / except / find' come around "green" (i.e.
generator expressions about half way through, Session 05).

When you have a clear understanding of all 33 keywords (or 35 or whatever),
that's a black belt, but like the come the many levels of black.

It's around Levels of Black that I feel more at my leisure to ponder a more
nuanced set of levels.  I'm thinking more in terms of workflows, like "solo
programmer" versus "on a team" leading to such as "version control" and
"sprints" i.e. we start to introduce the social and ritual activities
associated with life as a black belt, i.e. someone who knows what all the
keywords do.

Again, I'm allowing "black" to mean something rather naive and
inexperienced, at the bottom of a new ladder.  It's like, you've learned
enough English to tackle Shakespeare and the Bible, both great mountains.
You're looking up from below, lots to tackle.  By analogy now you're ready
to tackle your first web framework maybe, just using one, not designing one.

I'm not recommending something vague like "the Python community" adopt any
color coding scheme i.e. this is not about my failed attempt to suggest
standards to other schools.  I'm just inventing a local namespace that
suits my needs and suggesting other faculties might want to chunk it up
somehow and in a way more fine-grained than Beginner, Intermediate,
Advanced.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160202/855099eb/attachment.html>

From kirby.urner at gmail.com  Thu Feb 11 19:33:57 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 11 Feb 2016 16:33:57 -0800
Subject: [Edu-sig] from tonight's subject matter: algebra_city.py
Message-ID: <CAPJgG3RpNZJxJ9vSJ2kuvAMhcRXkWUSBi5toYfWVFVCeAoQB=w@mail.gmail.com>

# -*- coding: utf-8 -*-
"""
Created on Thu Feb 11 12:07:59 2016

@author: Kirby Urner

In algebra, we have the idea that functions might compose.  We
have this idea in POSIX too, i.e. the pipeline operator:

$ ls *.py | wc -l

The ls 'function' sends its output to wordcount -lines to say
how many Python modules in a give directory.

Instead of using a | (pipe) to chain or pipeline functions,
lets overload the multiplication and powering operators * and **.

Remember how lambda works to create a piece of functionality,
of one expression?

lambda x: f(g(x)) leaves the argument open i.e. we have not
committed to any special x.

lambda comes in handy below

The unittests would usually be split off into a separate file,
leaving algebra_city.py unencumbered with testing code, but
for now we develop them as one.
"""

import unittest
import types  # <-- to get FunctionType

class Composer:
    """
    Composer swallows a function, which may still be called, by
    calling the instance instead.  Used as a decorator, the Composer
    class enables composition of functions by means of multiplying
    and powering their corresponding Composer instances.
    """

    def __init__(self, func):
        self.func = func     # eat a callable

    def __call__(self, x):
        return self.func(x)  # still a callable

    def __mul__(self, other):
        """
        multiply two Composers i.e. (f * g)(x) == f(g(x))
        g might might a function. OK if f is Composer.
        """
        if isinstance(other, types.FunctionType): # OK if target is a
function
            other = Composer(other)
        if not isinstance(other, Composer): # by this point, other must be
one
            raise TypeError

        return Composer(lambda x: self.func(other.func(x)))  # compose 'em

    def __rmul__(self, other): # in case other is on the left
        """
        multiply two Composers i.e. (f * g)(x) == f(g(x))
        f might might a function. OK if g is Composer.
        """
        if isinstance(other, types.FunctionType): # OK if target is a
function
            other = Composer(other)
        if not isinstance(other, Composer): # by this point, other must be
one
            raise TypeError
        return Composer(lambda x: other.func(self.func(x)))  # compose 'em

    def __pow__(self, exp):
        """
        A function may compose with itself why not?
        """
        # type checking:  we want a non-negative integer
        if not isinstance(exp, int):
            raise TypeError
        if not exp > -1:
            raise ValueError
        me = self
        if exp == 0: # corner case
            return Composer(lambda x: x) # identify function
        elif exp == 1:
            return me                # (f**1) == f
        for _ in range(exp-1):       # e.g. once around loop if exp==2
            me = me * self
        return me

    def __repr__(self):
        return "Composer({})".format(self.func.__name__)

@Composer
def f(x):
    "second powering"
    return x ** 2

@Composer
def g(x):
    "magnifying by 10"
    return x * 10

class TestComposer(unittest.TestCase):

    def test_simple(self):
        x = 5
        self.assertEqual((f*g*g*f*g*f)(x), f(g(g(f(g(f(x)))))), "Not same!")

    def test_function(self):
        def addA(s): # not decorated
            return s + "A"
        @Composer
        def addM(s):
            return s + "M"

        addAM = addM * addA  # Composer times regular function, OK?
        self.assertEqual(addAM("I "), "I AM", "appends A then M")
        addMA = addA * addM  # regular function, times Composer OK?
        self.assertEqual(addMA("HI "), "HI MA", "appends M then A")

    def test_inputs(self):
        self.assertRaises(TypeError, f.__pow__, 2.0)  # float not OK!
        self.assertRaises(TypeError, f.__pow__, g)    # another function?
No!
        self.assertRaises(ValueError, f.__pow__, -1)  # negative number? No!

    def test_powering(self):
        self.assertEqual((f*f)(10), 10000, "2nd power of 2nd power")
        self.assertEqual((f**3)(4), f(f(f(4))), "Powering broken")
        h = (f**3) * (g**2)
        self.assertEqual(h(-11), f(f(f(g(g(-11))))), "Powering broken")
        self.assertEqual((f**0)(100), 100, "Identity function")

if __name__ == "__main__":
    unittest.main()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160211/757dd8fb/attachment.html>

From kirby.urner at gmail.com  Thu Feb 11 19:57:08 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 11 Feb 2016 16:57:08 -0800
Subject: [Edu-sig] a local peak (as in mountain top)
Message-ID: <CAPJgG3QM=KbOaMU_mxt0b577DN9aEvaKMd49qA8hR6=BuSSHeQ@mail.gmail.com>

In calculus we encounter "local maxima" in our manifold, i.e. mountain
peaks, from where the view is grand (other mountains stretch across the
horizon).

One such peak in Python is:  seeing a decorator turn a generator into a
context manager.

Getting this construct down may take more than one pass and certainly more
than one code sample.  The beauty is in so many concepts meshing together.
Epiphanies are possible, even likely.

In the code below, I'm building up "context manager" as a concept.  Our
theme at <guild /> is games, as in board games, even more than computer
games.

What would your job look like, if gamified i.e. turned into a board game?
Imagine inventing a board game to help a complete noobie learn the ropes.
What would be the rules, on the back of the box.  Now code it? The goal is
more something grammatically correct, than heavy duty.  It's a doodle, a
runnable poem.

The exercise of coding something one is familiar with, such as an
institution and its workflows, is about killing two virtual birds:
 learning the grammar of a new computer language; tackling programming as
an exercise in simulating, where the knowledge domain is one the student
already knows (e.g. working in a restaurant).

We see people tackling widgets in inventory, students in classrooms,
computing GPAs, but what about modeling the school more completely, or the
factory?  Invent some more classes e.g. FacultyMeeting.

I'll post one more example today, of what I consider intermediate
orange-to-green belt Python code i.e. ascending through keywords:

yield try: except: finally: with (with cm() as obj)

with added decorator syntax.

We already know about instances, class and static methods by this point.

We'll spiral back to yield later, to take on 'yield from' at a higher level.

Sticking to core Python with a cherry pick approach to modules, standard
library and 3rd party, is how I'm playing it.

The goal of the black belt is to not be stopped by any unknown keywords at
least, i.e. a reading knowledge of Python involves not remaining in the
dark about any of the core locutions / constructs.

But then each new level is also a chance to harness related, now more
within reach concepts.

Like when we get to yield (and the builtins: next send iter), that's the
time to stress "iterator" as an "interface" (in the sense of API) involving
__next__ and __iter__.

That discussion paves the way for the "interface" of a context manager
(__enter__ and __exit__), or a descriptor.

Also, each new level is a place to introduce more special names (or
__ribs__ as I sometimes call them).  We don't get to them all at once.

The special names are like Kanji (Chinese characters).  Add a few, get to
know them, add a few more, and so on.

Kirby


# -*- coding: utf-8 -*-
"""
Created on Thu Feb 11 10:16:34 2016

@author: Kirby Urner
"""

from collections import namedtuple
from random import randint

Survivor = namedtuple("Survivor", "name nick") # name, nickname

survivors = [Survivor("Joe","Dr. J."),
             Survivor("Sheila","Miss S."),
             Survivor("Eric","Monty"),
             Survivor("Prince","Prince"),
             Survivor("Thelma", "Da Queen"),
             Survivor("Peter", "the Spamster")]

class Game_Island:
    """
    VERY unconventional to not use 'self' as the instance placeholder
    but we're learning the grammar and therefore bend the rules
    """
    def __init__(island, survivors):  # context manager setup
        island.survivors = survivors

    def __enter__(island):
        return island # named Island within the context scope below

    def draw_straws(island):
        return island.survivors.pop(randint(0, len(island.survivors)-1))

    def __exit__(island, *exception_data):
        # maybe this isn't about exceptions, just crowning the winner
        print("The Last Survivor is...{winner.name} aka '{winner.nick}'".\
                format(winner=island.survivors[0]))
        if exception_data[0]:
            # uh oh....
            return False  # re-raise!  Something unexpected...
        return True


with Game_Island(survivors) as Island:  # Gilligan's?
    while len(Island.survivors) > 1:
        loser = Island.draw_straws()  # Island knows who they are
        print(("{loser.name} aka '{loser.nick}'" + \
        " is off the island").format(loser = loser))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160211/16ec7e2c/attachment-0001.html>

From kirby.urner at gmail.com  Thu Feb 11 20:03:29 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 11 Feb 2016 17:03:29 -0800
Subject: [Edu-sig] another example: modeling risk / learning to code
Message-ID: <CAPJgG3Rbv4rmZmnC+y4mmY7Q3nw2BU1-FBubP23EwZbK1HTaaQ@mail.gmail.com>

# -*- coding: utf-8 -*-
"""
Created on Thu Feb 11 09:08:42 2016

@author: Kirby Urner

A Game of Life (c) MIT License, 2016

Die:  2 or more sides
Cup:  1 or more dice

Exceptions subclasses

Run a gauntlet of possible exceptions, with Game for scope

"""
from random import choice

#==== What Could Go Wrong? ====
class TrafficTicket(Exception):
    def __init__(self, m=""):
        self.message = m

class GoToJail(Exception):
    pass

class SecondChance(Exception):
    pass

#==== Element of Chance =======
class Die:
    """
    * As many sides as you like, suggested minimum of two (like a coin)
    * Switch on record=True to keep a record of throws
    """

    def __init__(self, sides=6, record=False):
        self.sides = range(1, sides+1)
        self._throws = [ ]
        self.record = record

    @property  # treat as a simple attribute
    def throw(self):
        v = choice(self.sides)
        if self.record:
            self._history(v)
        return v

    def _history(self, value):
        self._throws.append(value)

    @property
    def history(self):
        if not self.record:
            raise AttributeError  # no record kept!
        return self._throws

class Cup:
    """
    Put as many dice as you like in the Cup. At least one.
    The dice should be passed in positionally as in
    Cup(Die(), Die())
    """

    def __init__(self, *dice):
        self._dice = dice

    def __getitem__(self, n):
        return self._dice[n]

    @property
    def throw(self):
        total = 0
        for die in self._dice:
            total += die.throw
        return total

def some_risky_business():
    """
    Take a turn, see what fate has in store!
    """

    venture_outcome = dice_cup.throw

    if venture_outcome == 12:
        # traffic misadventure
        raise TrafficTicket("No Left Turn!")

    elif venture_outcome == 2:
        # court finds your venture a Ponzi scheme
        raise GoToJail  # Monopoly maneuver

    elif choice(range(10)) == 7:  # not from dice!
        # starting over can be a good thing
        raise SecondChance

    else:
        print("So far so good...")

class Game:
    """
    Hi, I'm a context manager, like a gatekeeper,
    with an "in" and "out" method.  Upon leaving,
    I handle all exceptions
    """
    def __enter__(self):
        return self

    def __exit__(self, *exc_data):
        if exc_data[0]:   # exception happened
            print("Oh well.  Better luck next time!")
        else:
            print("Congratulations")
            # transcript is added to the game instance by the
            # else suite in the for loop below
            print("Lucky throws", self.transcript)
        return True  # OK, we're good

if __name__ == "__main__":

    with Game() as g:  # game object available within scope
        """
        If you're lucky, you won't roll a 2 or 12 in five
        rolls.  Otherwise, the exception handling machinery
        will deal with your case.  :-D
        """
        dice_cup = Cup(Die(record=True), Die(record=True))  # two dice
        while True:    # like an ever turning wheel of fortune...
            turns = 0
            try:
                for _ in range(5):
                    some_risky_business() # returns None ...
                else:
                    print("You lucked out!")
                    # adding the two histories gives a record of Cup throws
                    # making an attribute of the game object
                    g.transcript = [sum([i,j]) for i,j in
zip(dice_cup[0].history,
                                                       dice_cup[1].history)]

            # an exception will occur...
            except TrafficTicket as exc:
                print(exc.message)
                raise  # propagate loose end!

            except GoToJail:
                print("GoToJail raised")
                raise  # re-raise same exception

            except SecondChance:
                print("Get to start over!")
                continue  # turns reset to 0

            else:
                print("You tried, and succeeded!")
                break  # escape from the Wheel of Risk

    print("There's still life after scope")
    print("The dice_cup is still with us....")
    for _ in range(4):
        print(dice_cup.throw, end=" ")
    print()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160211/d2fc6942/attachment.html>

From kirby.urner at gmail.com  Mon Feb 15 14:02:59 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 15 Feb 2016 11:02:59 -0800
Subject: [Edu-sig] what is a "variable" in Python?
Message-ID: <CAPJgG3SG5L7P23Nq-f0bpF1hV8KU0eq0V1Ao8mWcGphy_UKcpg@mail.gmail.com>

What do educators think about this discussion of variables in Python?

http://www.python-course.eu/variables.php

I find the "variable versus identifier" discussion, with repeated
references to C / C++, to be somewhat on the confusing side.

My view is "variable as container" makes sense if you're talking about the
object itself, on the heap, e.g. the list, dict or tuple or whatever.

I might write the word "Object" with a big "O" and say that represents "a
container in memory" (contains data and methods e.g. datetime.datetime
objects).

But then I'd say said object is "variable" only if it's mutable i.e. it
could be a constant (immutable) in contrast.  Strings and integers are not
"variables" as you can't do anything to mutate them.  Lists are variables,
strings are not.

Names, on the other hand, are like postits or luggage tags, more like
labels for objects, and we can pull a postit (like X) from an object (like
'A') and stick it on another object (say 3) instead.

This is *not* a matter of a variable changing i.e.

X = 'A'
X = 3

has nothing to do with "changing the content of a container" (as if 3 had
to fit into the same piece of memory as the 'A' did) but is rather about
slapping the name 'X' onto two different objects in quick succession.
Identifiers don't care what they stick to, as long as they're objects.

Objects always have type.

Names are just names:  they name things with type, i.e. objects.

It's not that mysterious -- but the "container" metaphor gets in the way
when you go:

>>> A = [1,2,3]
>>> B = A
>>> B[-1]=4
>>> A[2]
4

and then maybe think A should be pictured as a container with [1,2,3]
inside it.  So does B have [1,2,3] inside it too, meaning it's own copy?
Of course not, but two "containers" cannot logically "contain" the same
object which is why there's cognitive stress.  The "container" metaphor is
obstructive.

B and A are simply two postits, two tags, affixed to the same object, the
list on the heap, no big deal.

You can call that object a "variable" if you like, but why not just call it
a "mutable object" instead?

On the other hand, A and B are just names in the namespace.  We use them to
talk to / remotely control said objects, not just name them.  Names don't
have type and we don't name names, we name objects.

A name is a lot like a TV remote, with lots of buttons (dot notation
activated, lots of little callables).  An object is a lot like the TV.

More than one remote controlling the same TV is OK in Python.

There is no "container" in this picture unless you want to say the TV is a
container (an object), in which case I'd agree.  Saying the remote
"contains" the TV is not helpful and just gets in the way the second you
have two remotes for the same object.

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/87c7ca7d/attachment.html>

From naomi.ceder at gmail.com  Mon Feb 15 14:15:34 2016
From: naomi.ceder at gmail.com (Naomi Ceder)
Date: Mon, 15 Feb 2016 13:15:34 -0600
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAPJgG3SG5L7P23Nq-f0bpF1hV8KU0eq0V1Ao8mWcGphy_UKcpg@mail.gmail.com>
References: <CAPJgG3SG5L7P23Nq-f0bpF1hV8KU0eq0V1Ao8mWcGphy_UKcpg@mail.gmail.com>
Message-ID: <CAKvj0qQzWZ0LWQn-UvUtfZmA5zXVKtestPEUGsGauV34Ybr=zQ@mail.gmail.com>

The short answer is that I agree with you.

In fact, the link you shared is an example of my favourite incorrect mental
model, which even prompted me to post this rant
https://learnpython.wordpress.com/2015/05/21/notes-on-teaching-python-mental-models/
some months ago.

TL;DR - "in Python 'variables' are post-its, not buckets". (to use one of
my own homely metaphors)

Cheers,
Naomi

On 15 February 2016 at 13:02, kirby urner <kirby.urner at gmail.com> wrote:

>
> What do educators think about this discussion of variables in Python?
>
> http://www.python-course.eu/variables.php
>
> I find the "variable versus identifier" discussion, with repeated
> references to C / C++, to be somewhat on the confusing side.
>
> My view is "variable as container" makes sense if you're talking about the
> object itself, on the heap, e.g. the list, dict or tuple or whatever.
>
> I might write the word "Object" with a big "O" and say that represents "a
> container in memory" (contains data and methods e.g. datetime.datetime
> objects).
>
> But then I'd say said object is "variable" only if it's mutable i.e. it
> could be a constant (immutable) in contrast.  Strings and integers are not
> "variables" as you can't do anything to mutate them.  Lists are variables,
> strings are not.
>
> Names, on the other hand, are like postits or luggage tags, more like
> labels for objects, and we can pull a postit (like X) from an object (like
> 'A') and stick it on another object (say 3) instead.
>
> This is *not* a matter of a variable changing i.e.
>
> X = 'A'
> X = 3
>
> has nothing to do with "changing the content of a container" (as if 3 had
> to fit into the same piece of memory as the 'A' did) but is rather about
> slapping the name 'X' onto two different objects in quick succession.
> Identifiers don't care what they stick to, as long as they're objects.
>
> Objects always have type.
>
> Names are just names:  they name things with type, i.e. objects.
>
> It's not that mysterious -- but the "container" metaphor gets in the way
> when you go:
>
> >>> A = [1,2,3]
> >>> B = A
> >>> B[-1]=4
> >>> A[2]
> 4
>
> and then maybe think A should be pictured as a container with [1,2,3]
> inside it.  So does B have [1,2,3] inside it too, meaning it's own copy?
> Of course not, but two "containers" cannot logically "contain" the same
> object which is why there's cognitive stress.  The "container" metaphor is
> obstructive.
>
> B and A are simply two postits, two tags, affixed to the same object, the
> list on the heap, no big deal.
>
> You can call that object a "variable" if you like, but why not just call
> it a "mutable object" instead?
>
> On the other hand, A and B are just names in the namespace.  We use them
> to talk to / remotely control said objects, not just name them.  Names
> don't have type and we don't name names, we name objects.
>
> A name is a lot like a TV remote, with lots of buttons (dot notation
> activated, lots of little callables).  An object is a lot like the TV.
>
> More than one remote controlling the same TV is OK in Python.
>
> There is no "container" in this picture unless you want to say the TV is a
> container (an object), in which case I'd agree.  Saying the remote
> "contains" the TV is not helpful and just gets in the way the second you
> have two remotes for the same object.
>
> Kirby
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
>


-- 
Naomi Ceder
https://plus.google.com/u/0/111396744045017339164/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/4f43954b/attachment.html>

From kirby.urner at gmail.com  Mon Feb 15 14:42:00 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 15 Feb 2016 11:42:00 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAKvj0qQzWZ0LWQn-UvUtfZmA5zXVKtestPEUGsGauV34Ybr=zQ@mail.gmail.com>
References: <CAPJgG3SG5L7P23Nq-f0bpF1hV8KU0eq0V1Ao8mWcGphy_UKcpg@mail.gmail.com>
 <CAKvj0qQzWZ0LWQn-UvUtfZmA5zXVKtestPEUGsGauV34Ybr=zQ@mail.gmail.com>
Message-ID: <CAPJgG3RiZ6ekQLxgEcWuaCnoGh8oxJ+C0BUrzBHXiq=yLWxCxg@mail.gmail.com>

Perfect!

That's exactly the right rant!  Thank you Naomi.

Python names are post-its, not buckets.  You effectively counter the
"bucket brigade".  Hah hah.

Here's me chatting with Steve Holden a few minutes ago, across many time
zones (dinner time there, just getting to be lunch time here).

===

*Kirby*:  This posting of two minutes ago goes back to your laptop drawings
at Pycon, of namespace versus objectspace.  An ongoing theme in Python
Pedagogy...
https://mail.python.org/pipermail/edu-sig/2016-February/011372.html
<https://www.google.com/url?q=https%3A%2F%2Fmail.python.org%2Fpipermail%2Fedu-sig%2F2016-February%2F011372.html&sa=D&sntz=1&usg=AFQjCNGIza5x8WaXR0iMd7N8XJ1XzWjAtg>

*Steve*: And yet I have had arguments with people who complain when I say
that names in Python are simply object references

*Kirby*: They're references with hooks in that dot notation becomes a
conduit i.e. one applies A.method() to A to control whatever A names.  So a
name is a reference with controller capabilities?  It's not quite like a
luggage tag, so much as a TV remote.  You can press the tag in such a way
as to make the suitcase snap open.

*Steve*: I'd rather say dot notation is a way of changing the namespace in
which a name is expected to be found.  If that's "controlling" then we agree

*Kirby*: Given the name exists, e.g. A, using A.method() does not alter the
namespace though, i.e. A is still the only name we've got.  A may have
mutated nonetheless e.g. L.sort().

*Steve*: What I meant was that A.b means that b is looked up in A's
namespace

*Kirby*: Yes.  A TV remote is a namespace in that each button belongs to
the remote.  R.on, R.off, R.volume(+1) etc.  The TV is what R controls i.e.
is the object R names.

*Steve*: There is nothing a function/method can to to alter which object is
bound to a name used as a variable because bindings to arguments occur only
the function/method's namespace. It can, however, mutate the objects to
which it is passed references.

*Kirby*: In my posting to edu-sig I suggest that objects may be constant or
variable, corresponding to immutable versus mutable.  Names, however, in
being simply identifiers, are not themselves "variables".  The list itself
is a variable (a mutable object).  The name L is simply a name.  And it
should not be represented as a "container" of something.

*Steve*: Later. Dinner time now!

*Kirby*: OK, eat hardy!



On Mon, Feb 15, 2016 at 11:15 AM, Naomi Ceder <naomi.ceder at gmail.com> wrote:

> The short answer is that I agree with you.
>
> In fact, the link you shared is an example of my favourite incorrect
> mental model, which even prompted me to post this rant
> https://learnpython.wordpress.com/2015/05/21/notes-on-teaching-python-mental-models/
> some months ago.
>
> TL;DR - "in Python 'variables' are post-its, not buckets". (to use one of
> my own homely metaphors)
>
> Cheers,
> Naomi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/a3ead876/attachment-0001.html>

From litvin at skylit.com  Mon Feb 15 15:19:27 2016
From: litvin at skylit.com (Litvin)
Date: Mon, 15 Feb 2016 15:19:27 -0500
Subject: [Edu-sig] what is a "variable" in Python?
Message-ID: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/e04dd592/attachment.html>

From kirby.urner at gmail.com  Mon Feb 15 16:41:06 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 15 Feb 2016 13:41:06 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
Message-ID: <CAPJgG3RpfBrcE__7A4dv9GDKt2BJAkeXDDuJKaXpH_ZPyk=ppw@mail.gmail.com>

No need to say "sorry" as if an honest disagreement were a cause for
regret.  I enjoy diversity.  What would life be without different
perspectives?  Plain vanilla.

I'm familiar with the mental model of which you speak and was for years
myself not a Python programmer, with miles of source code to my name.  But
so what?  Python is different than C which is different than Erlang and so
on.

So be prepared, ye novices, to pay special close attention to how we say
"variable" and/or "keyword" or whatever.

Like we both agree "keyword" means something else entirely in Clojure.  And
so it is with these computer languages:  all subtly parallel universes of
each other, in how they sling the jargon:  familiar, yet strange.

"Yes, exactly, so pay close attention" -- that's me reminding even seasoned
C programmers, whom I have in my <guild /> classes (or class, I'm new there
[1]), that each language is a little different.

We also both agree that "immutable" versus "mutable" is a characteristic of
objects, not the "remotes" (objects as TVs, usually quite mutable on
average), not the luggage tags (objects = suitcases).

Names are neither mutable nor immutable just easily re-assignable.  I pull
an "X" off a 3 and stick it to a steam engine instead, they're both
objects, no problemo.

But some are mutable, change state.  Inattention to this difference,
postponing it as "advanced" is highly inadvisable, even dangerous.  Learn
the difference right away!

And why not.  The assignment part just was *not* that hard.  Removing the
"container" metaphor (as if we needed "variables" in addition to "names and
objects") will for some students be the stroke of lightning that finally
makes it all come together.  Why?

Because containership is at cross-purposes to how Python never copies
implicitly, when you keep assigning names to names ala A = B.  How do five
"containers" all "contain the same thing"?  That's the core of the "buckets
versus postits" controversy and whereas you say you disagree, you have yet
to take that bull by the horns.  The assignment operator is not in your
favor as Label = 3 is precisely affixing a tag to 3, not embracing and
containing 3 in some spooky object called Label (take that route and you're
forever the dazed and confused C programmer in Python Land).

You should expect a percentage of your students to achieve illumination by
this insight.  You defend a conventional dogma and disagree with my
teaching.  I'm proud of that difference and charge yet more money for that
reason. So again, don't be sorry.  :-D

Kirby

[1] https://www.flickr.com/photos/kirbyurner/albums/72157664250599655



On Mon, Feb 15, 2016 at 12:19 PM, Litvin <litvin at skylit.com> wrote:

> Sorry, I don't agree.  Thinking of variables as named containers is not an
> "incorrect mental model" but a useful metaphor for teaching programming to
> novices.  In my mental model, variable is called a "variable" because it
> can hold  different values at different times.  This has nothing to do with
> immutability.  Immutability applies to objects, not variables; an immutable
> object cannot change its state after it has been created, regardless where
> it is stored.  A tuple is immutable but a variable can hold different
> tuples.  Immutability is a more difficult, OOP concept, and the discussion
> of immutability does not belong with  an introductory topic of variables.
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/2086ff14/attachment.html>

From macquigg at ece.arizona.edu  Mon Feb 15 17:26:09 2016
From: macquigg at ece.arizona.edu (David MacQuigg)
Date: Mon, 15 Feb 2016 15:26:09 -0700
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
Message-ID: <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>

Seems like the difference is merely a matter of how we define the word
"variable".  Is it the label, or is it the object?  I've always thought of
it as being the label.  Here is how I explained Python "variables" to
engineering students (who were taking a class on C).  Maybe I should have
used the word "labels" instead.
http://www2.engr.arizona.edu/~edatools/ece175/Lecture/python-variables.htm

This discussion reminds me of the controversy over whether Python functions
are call-by-value or call-by-reference.
http://www2.engr.arizona.edu/~edatools/ece175/Lecture/calling_methods.py
I like Bruce Eckel's sidestep on this issue.
http://www2.engr.arizona.edu/~edatools/ece175/Lecture/QnA.txt
"In the end, it isn't that important. What is important is that you
understand that passing a reference allows the caller's object to be changed
unexpectedly."

David MacQuigg, PhD


On Mon, Feb 15, 2016 at 1:19 PM, Litvin <litvin at skylit.com> wrote:

> Sorry, I don't agree.  Thinking of variables as named containers is not an
> "incorrect mental model" but a useful metaphor for teaching programming to
> novices.  In my mental model, variable is called a "variable" because it
> can hold  different values at different times.  This has nothing to do with
> immutability.  Immutability applies to objects, not variables; an immutable
> object cannot change its state after it has been created, regardless where
> it is stored.  A tuple is immutable but a variable can hold different
> tuples.  Immutability is a more difficult, OOP concept, and the discussion
> of immutability does not belong with  an introductory topic of variables.
>
> Putting postits on, say, numbers is hard to swallow.  After all, = is
> called an assignment operator, not a naming operator.  Novices have enough
> trouble remembering what is assigned to whom.  The only difference between
> Python and a strongly typed language is that Python's "containers" are
> flexible: they can hold values of different types at different times.  So
> in Python, a  container does not have a type, only the value that it
> currently holds.  This is not too hard for students to grasp.
>
> Kirby's link has a confused discussion of identifiers and in general may
> be not the best way of introducing variables, but one confusing page
> doesn't warrant wholesale revision of concepts that have been successfully
> taught for decades and apply to other languages that a student might know
> or will encounter in the future.  Just my 2c.
>
> Gary Litvin
> www.skylit.com
>
> At 02:15 PM 2/15/2016, you wrote:
>
> The short answer is that I agree with you.?
>
> In fact, the link you shared is an example of my favourite incorrect
> mental model, which even prompted me to post this rant?
> https://learnpython.wordpress.com/2015/05/21/notes-on-teaching-python-mental-models/
> some months ago.?
>
> TL;DR - "in Python 'variables' are post-its, not buckets". (to use one of
> my own homely metaphors)
>
> Cheers,
> Naomi
>
> On 15 February 2016 at 13:02, kirby urner <kirby.urner at gmail.com> wrote: What
> do educators think about this discussion of variables in Python?
>
> http://www.python-course.eu/variables.php
> I find the "variable versus identifier" discussion, with repeated
> references to C / C++, to be somewhat on the confusing side.
> My view is "variable as container" makes sense if you're talking about the
> object itself, on the heap, e.g. the list, dict or tuple or whatever.?
> I might write the word "Object" with a big "O" and say that represents "a
> container in memory" (contains data and methods e.g. datetime.datetime
> objects).
> But then I'd say said object is "variable" only if it's mutable i.e. it
> could be a constant (immutable) in contrast.?  Strings and integers are not
> "variables" as you can't do anything to mutate them.?  Lists are variables,
> strings are not.
> Names, on the other hand, are like postits or luggage tags, more like
> labels for objects, and we can pull a postit (like X) from an object (like
> 'A') and stick it on another object (say 3) instead.? ?
> This is *not* a matter of a variable changing i.e.
>
> X = 'A' X = 3
> has nothing to do with "changing the content of a container" (as if 3 had
> to fit into the same piece of memory as the 'A' did) but is rather about
> slapping the name 'X' onto two different objects in quick succession.?
> Identifiers don't care what they stick to, as long as they're objects.
> Objects always have type.?
> Names are just names:?  they name things with type, i.e. objects.?
> It's not that mysterious -- but the "container" metaphor gets in the way
> when you go:
> >>> A = [1,2,3] >>> B = A >>> B[-1]=4 >>> A[2] 4
> and then maybe think A should be pictured as a container with [1,2,3]
> inside it.?  So does B have [1,2,3] inside it too, meaning it's own copy??
> Of course not, but two "containers" cannot logically "contain" the same
> object which is why there's cognitive stress.?  The "container" metaphor is
> obstructive.
> B and A are simply two postits, two tags, affixed to the same object, the
> list on the heap, no big deal.?
> You can call that object a "variable" if you like, but why not just call
> it a "mutable object" instead??
> On the other hand, A and B are just names in the namespace.?  We use them
> to talk to / remotely control said objects, not just name them.?  Names
> don't have type and we don't name names, we name objects.
> A name is a lot like a TV remote, with lots of buttons (dot notation
> activated, lots of little callables).?  An object is a lot like the TV.?
> More than one remote controlling the same TV is OK in Python.?
> There is no "container" in this picture unless you want to say the TV is a
> container (an object), in which case I'd agree.?  Saying the remote
> "contains" the TV is not helpful and just gets in the way the second you
> have two remotes for the same object.
> Kirby
>
>
> _______________________________________________ Edu-sig mailing list
> Edu-sig at python.org https://mail.python.org/mailman/listinfo/edu-sig
>
>
>
>
> --
> Naomi Ceder
> https://plus.google.com/u/0/111396744045017339164/about
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7442 / Virus Database: 4530/11630 - Release Date: 02/15/16
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/73adc655/attachment-0001.html>

From kirby.urner at gmail.com  Mon Feb 15 18:30:41 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 15 Feb 2016 15:30:41 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
Message-ID: <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>

http://www2.engr.arizona.edu/~edatools/ece175/Lecture/python-variables.htm

seems completely unobjectionable (forgive pun).

The notion of a Python variable inherits from lamba x: x + 1 i.e. we don't
specify the x and so map(lambda x: x + 1, [1, 2.0, Decimal(3)]) makes sense
with all these differently typed inputs.

In [8]: list(map(lambda x: x + 1, [1, 2.0, Decimal(3)]))
Out[8]: [2, 3.0, Decimal('4')]

I'm using I-Python inside Spyder these days when I project.

But what's actually going on here is well-expressed by the word "binding".
We say a name is "bound to" an object which again does not intuitively
suggest "put inside of".

Some of us teach Python without inducing thoughts of little boxes (buckets)
whereas others of us want to use that.  There's diversity in our midst and
this is not a cause for either alarm or skulking.

I'm glad edu-sig is getting used for its stated purpose in any case.  You
can bet I'm pointing a lot of people to this thread as I emphasize the
importance of mental models.

I take it further than Naomi with my TV remote analogy.

That's an analogy that works especially well with the Netflix couch potato
crowd, some of whom show up at code school anxious to work out.  In
cultures where TV remotes are not familiar objects, I would hesitate to
make such abundant use of it in my lectures.

Kirby



On Mon, Feb 15, 2016 at 2:26 PM, David MacQuigg <macquigg at ece.arizona.edu>
wrote:

> Seems like the difference is merely a matter of how we define the word
> "variable".  Is it the label, or is it the object?  I've always thought of
> it as being the label.  Here is how I explained Python "variables" to
> engineering students (who were taking a class on C).  Maybe I should have
> used the word "labels" instead.
> http://www2.engr.arizona.edu/~edatools/ece175/Lecture/python-variables.htm
>
> This discussion reminds me of the controversy over whether Python
> functions are call-by-value or call-by-reference.
> http://www2.engr.arizona.edu/~edatools/ece175/Lecture/calling_methods.py
> I like Bruce Eckel's sidestep on this issue.
> http://www2.engr.arizona.edu/~edatools/ece175/Lecture/QnA.txt
> "In the end, it isn't that important. What is important is that you
> understand that passing a reference allows the caller's object to be
> changed
> unexpectedly."
>
> David MacQuigg, PhD
>
>
> On Mon, Feb 15, 2016 at 1:19 PM, Litvin <litvin at skylit.com> wrote:
>
>> Sorry, I don't agree.  Thinking of variables as named containers is not
>> an "incorrect mental model" but a useful metaphor for teaching programming
>> to novices.  In my mental model, variable is called a "variable" because it
>> can hold  different values at different times.  This has nothing to do with
>> immutability.  Immutability applies to objects, not variables; an immutable
>> object cannot change its state after it has been created, regardless where
>> it is stored.  A tuple is immutable but a variable can hold different
>> tuples.  Immutability is a more difficult, OOP concept, and the discussion
>> of immutability does not belong with  an introductory topic of variables.
>>
>> Putting postits on, say, numbers is hard to swallow.  After all, = is
>> called an assignment operator, not a naming operator.  Novices have enough
>> trouble remembering what is assigned to whom.  The only difference between
>> Python and a strongly typed language is that Python's "containers" are
>> flexible: they can hold values of different types at different times.  So
>> in Python, a  container does not have a type, only the value that it
>> currently holds.  This is not too hard for students to grasp.
>>
>> Kirby's link has a confused discussion of identifiers and in general may
>> be not the best way of introducing variables, but one confusing page
>> doesn't warrant wholesale revision of concepts that have been successfully
>> taught for decades and apply to other languages that a student might know
>> or will encounter in the future.  Just my 2c.
>>
>> Gary Litvin
>> www.skylit.com
>>
>> At 02:15 PM 2/15/2016, you wrote:
>>
>> The short answer is that I agree with you.?
>>
>> In fact, the link you shared is an example of my favourite incorrect
>> mental model, which even prompted me to post this rant?
>> https://learnpython.wordpress.com/2015/05/21/notes-on-teaching-python-mental-models/
>> some months ago.?
>>
>> TL;DR - "in Python 'variables' are post-its, not buckets". (to use one of
>> my own homely metaphors)
>>
>> Cheers,
>> Naomi
>>
>> On 15 February 2016 at 13:02, kirby urner <kirby.urner at gmail.com> wrote: What
>> do educators think about this discussion of variables in Python?
>>
>> http://www.python-course.eu/variables.php
>> I find the "variable versus identifier" discussion, with repeated
>> references to C / C++, to be somewhat on the confusing side.
>> My view is "variable as container" makes sense if you're talking about
>> the object itself, on the heap, e.g. the list, dict or tuple or whatever.?
>> I might write the word "Object" with a big "O" and say that represents "a
>> container in memory" (contains data and methods e.g. datetime.datetime
>> objects).
>> But then I'd say said object is "variable" only if it's mutable i.e. it
>> could be a constant (immutable) in contrast.?  Strings and integers are not
>> "variables" as you can't do anything to mutate them.?  Lists are variables,
>> strings are not.
>> Names, on the other hand, are like postits or luggage tags, more like
>> labels for objects, and we can pull a postit (like X) from an object (like
>> 'A') and stick it on another object (say 3) instead.? ?
>> This is *not* a matter of a variable changing i.e.
>>
>> X = 'A' X = 3
>> has nothing to do with "changing the content of a container" (as if 3 had
>> to fit into the same piece of memory as the 'A' did) but is rather about
>> slapping the name 'X' onto two different objects in quick succession.?
>> Identifiers don't care what they stick to, as long as they're objects.
>> Objects always have type.?
>> Names are just names:?  they name things with type, i.e. objects.?
>> It's not that mysterious -- but the "container" metaphor gets in the way
>> when you go:
>> >>> A = [1,2,3] >>> B = A >>> B[-1]=4 >>> A[2] 4
>> and then maybe think A should be pictured as a container with [1,2,3]
>> inside it.?  So does B have [1,2,3] inside it too, meaning it's own copy??
>> Of course not, but two "containers" cannot logically "contain" the same
>> object which is why there's cognitive stress.?  The "container" metaphor is
>> obstructive.
>> B and A are simply two postits, two tags, affixed to the same object, the
>> list on the heap, no big deal.?
>> You can call that object a "variable" if you like, but why not just call
>> it a "mutable object" instead??
>> On the other hand, A and B are just names in the namespace.?  We use them
>> to talk to / remotely control said objects, not just name them.?  Names
>> don't have type and we don't name names, we name objects.
>> A name is a lot like a TV remote, with lots of buttons (dot notation
>> activated, lots of little callables).?  An object is a lot like the TV.?
>> More than one remote controlling the same TV is OK in Python.?
>> There is no "container" in this picture unless you want to say the TV is
>> a container (an object), in which case I'd agree.?  Saying the remote
>> "contains" the TV is not helpful and just gets in the way the second you
>> have two remotes for the same object.
>> Kirby
>>
>>
>> _______________________________________________ Edu-sig mailing list
>> Edu-sig at python.org https://mail.python.org/mailman/listinfo/edu-sig
>>
>>
>>
>>
>> --
>> Naomi Ceder
>> https://plus.google.com/u/0/111396744045017339164/about
>> _______________________________________________
>> Edu-sig mailing list
>> Edu-sig at python.org
>> https://mail.python.org/mailman/listinfo/edu-sig
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2016.0.7442 / Virus Database: 4530/11630 - Release Date: 02/15/16
>>
>>
>> _______________________________________________
>> Edu-sig mailing list
>> Edu-sig at python.org
>> https://mail.python.org/mailman/listinfo/edu-sig
>>
>>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> https://mail.python.org/mailman/listinfo/edu-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/219d4c3e/attachment.html>

From kirby.urner at gmail.com  Mon Feb 15 21:58:36 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 15 Feb 2016 18:58:36 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
Message-ID: <CAPJgG3TgVAjyU_xS5Jhq+Vbi=g85TCDV9Wv0_ZAu6AeVNYrC1Q@mail.gmail.com>

On Mon, Feb 15, 2016 at 5:23 PM, Carl Karsten <carl at nextdayvideo.com> wrote:

> I think the point of this thread is: how important is this subject?
>
>
I don't know that there's a scale of 1-10 answer.  If / when it comes up,
as a student question, it becomes important, but also instructors need to
explain how a given object may have many names, whereas of we're focused on
"containers" how does that look?



> I have one of many answers: in my 2 hour 500 line intro to python, it gets
> about 60 seconds spent on this 1 line:
>
> """Other languages have variables; technically, Python doesn't. But it has
> something that looks like a var: It has names. So don't call it a var. For
> a good explanation of this see
> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
> """
>

This is excellent.

I was racking my brains where to find visuals like this, specifically
showing the buckets versus post-its models.

I've added links to my make_links_v2.py and make_links_v3.py @ <guild /> [1]

This thread was useful for our trains at PDX Code Guild at least, as I'm
having philosophical differences with some of my peers regarding the
uber-basics and how best to teach them.

I've been told repeatedly that code school students will start out *not*
knowing what a variable is and my number one most important responsibility,
right from the get go, is to introduce the concept.

Fine.  But what if the curriculum hard-codes that we should see variables
as "containers".

Before I lead a boot camp, Python-centric, I want to make sure I'm not
shackled to a misinforming presentation I'm not comfortable teaching.  It'd
just feel wrong, like I'm lying, to force the "container metaphor".  I
needed ammo.

By now, thanks to these threads today, I feel well armed in my views that
I'm free to avoid said metaphor if I want to.

Here's a screen shot of our faculty Slack feed from a few minutes ago:

https://flic.kr/p/DduBoA

There's enough consensus out there to defend my position.  Yay.

What I want to avoid is another instructor insisting on the "variable as
container" metaphor to a point where I feel I have to do extra work to undo
that picture.

Thanks again for the tools, should that come up.

Kirby

[1]
https://www.dropbox.com/home/PDX%20Code%20Guild/Accelerated%20Programming%20%28fork%29
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/e73665aa/attachment-0001.html>

From aharrin at luc.edu  Mon Feb 15 23:48:32 2016
From: aharrin at luc.edu (Andrew Harrington)
Date: Mon, 15 Feb 2016 22:48:32 -0600
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
 <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
Message-ID: <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>

I agree with Gary that mutability is a property of objects, not of
variables. An object has methods.  A name does not - it can refer to an
object with a particular method.  I do not get the variable and remote
buttons analogy at all. The importance of a variable naming a memory
*location* with a reference is that clearly there can be only one reference
at that memory location at a time.  There is nothing saying with the
English word "label" that two different objects/places could not have the
same naming label slapped on them, so relying too heavily on easy English
analogies is tricky.

In my Hands-on Python Tutorial <http://anh.cs.luc.edu/python/hands-on/3.1>
I say all data has a type, and I start with immutable objects types.  I say
initially that a variable is a name used to refer to a piece of data.  Much
later I get to mutable objects, and then the idea of a reference to an
object is key to understanding.  I point out that with immutable objects
this does not make much difference, but when we start dealing with mutable
objects, it is important to be more precise.  This sequence seems to work
fine.

Andy

Dr. Andrew N. Harrington
  Computer Science Department
  Graduate Program Director gpd at cs.luc.edu
  Loyola University Chicago
  529 Lewis Towers, 111 E. Pearson St. (Downtown)
  417 Cudahy Science Hall (Rogers Park campus)
http://www.cs.luc.edu/~anh
Phone: 312-915-7982
Fax:    312-915-7998
aharrin at luc.edu (as professor, not gpd role)

On Mon, Feb 15, 2016 at 8:58 PM, kirby urner <kirby.urner at gmail.com> wrote:

>
>
> On Mon, Feb 15, 2016 at 5:23 PM, Carl Karsten <carl at nextdayvideo.com>
> wrote:
>
>> I think the point of this thread is: how important is this subject?
>>
>>
> I don't know that there's a scale of 1-10 answer.  If / when it comes up,
> as a student question, it becomes important, but also instructors need to
> explain how a given object may have many names, whereas of we're focused on
> "containers" how does that look?
>
>
>
>> I have one of many answers: in my 2 hour 500 line intro to python, it
>> gets about 60 seconds spent on this 1 line:
>>
>> """Other languages have variables; technically, Python doesn't. But it
>> has something that looks like a var: It has names. So don't call it a var.
>> For a good explanation of this see
>> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
>> """
>>
>
> This is excellent.
>
> I was racking my brains where to find visuals like this, specifically
> showing the buckets versus post-its models.
>
> I've added links to my make_links_v2.py and make_links_v3.py @ <guild />
> [1]
>
> This thread was useful for our trains at PDX Code Guild at least, as I'm
> having philosophical differences with some of my peers regarding the
> uber-basics and how best to teach them.
>
> I've been told repeatedly that code school students will start out *not*
> knowing what a variable is and my number one most important responsibility,
> right from the get go, is to introduce the concept.
>
> Fine.  But what if the curriculum hard-codes that we should see variables
> as "containers".
>
> Before I lead a boot camp, Python-centric, I want to make sure I'm not
> shackled to a misinforming presentation I'm not comfortable teaching.  It'd
> just feel wrong, like I'm lying, to force the "container metaphor".  I
> needed ammo.
>
> By now, thanks to these threads today, I feel well armed in my views that
> I'm free to avoid said metaphor if I want to.
>
> Here's a screen shot of our faculty Slack feed from a few minutes ago:
>
> https://flic.kr/p/DduBoA
>
> There's enough consensus out there to defend my position.  Yay.
>
> What I want to avoid is another instructor insisting on the "variable as
> container" metaphor to a point where I feel I have to do extra work to undo
> that picture.
>
> Thanks again for the tools, should that come up.
>
> Kirby
>
> [1]
> https://www.dropbox.com/home/PDX%20Code%20Guild/Accelerated%20Programming%20%28fork%29
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/0cb873ff/attachment.html>

From kirby.urner at gmail.com  Tue Feb 16 01:52:08 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 15 Feb 2016 22:52:08 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
 <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
 <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>
Message-ID: <CAPJgG3QXngOK0011niUVqxUXD=hcrpXrdnadx++_fLBSGhtxdw@mail.gmail.com>

On Mon, Feb 15, 2016 at 8:48 PM, Andrew Harrington <aharrin at luc.edu> wrote:

> I agree with Gary that mutability is a property of objects, not of
> variables.
>


I think everyone who has put in two cents so far, including me, agrees with
this point.

The only rewording I might suggest is "mutability is a property of objects,
not names" (saying "names" instead of "variables") as I think it's fine to
introduce Python to newbies without using the word "variable" (certainly
not to mean "container" if used).

"Names and objects" are sufficient to start with.  Occam's Razor and all
that.

Some names aren't bound until run time, as happens when list(map(lambda
x,y: x+y, ["T"], ["ED"])) actually executes:

In[3]: list(map(lambda x,y: x+y, ["T"], ["ED"]))
Out[3]: ['TED']

Names often get bound to objects without any need of the assignment
operator.

def F():
   <function body>

does name binding, of a name (F) to some callable object.

The for loop is another example, of binding without need of the assignment
operator (=):

for x in H:
   body of loop

shows how the same label, x, may be applied to items in succession.  This x
doesn't "contain" objects in H one by one, it merely tags them, and thereby
gives code in the loop body an opportunity for controlling them.

The assignment operator is a binding operator, in that it binds names to
objects.  Names do not "swallow" objects and take them prisoner.  Names are
not cells. Names have no internals.

But then dot notation is often applied to them.

aTV.on() controls some instance on the heap.

aTV is a name with no TV "inside" it.  aTV is remote from the TV, yet bound
to it.

Objects themselves are aptly modeled as containers, sure, and have both
methods and data (typically) internally.  Objects are what's complex.
Names are simple (no internals).

An object is typically mutable but of course not always -- an important
distinction that should be front and center, once "naming" ("assigning") is
understood.



> An object has methods.  A name does not - it can refer to an object with a
> particular method.
>

An object (noun) has these various verbs that we might call (__call__), but
we do so using Python names (identifiers) most typically.

3 .__add__(2) makes sense, i.e. an int or string literal or "naked object"
may be the subject of a method (e.g. "ABC".lower()).

Usually though, we'd need a name for our objects, having no "naked"
(syntactically primitive) form.  The name anchors a surrounding namespace,
of the methods and attributes therewith associated.

A name is inside a namespace, and likewise comprises a namespace (with dot
methods and dot attributes).  The name remains distinct from the object
itself in memory (on the heap).

The TV remote idea is:  if I aim a remote at a TV, it has __on__ and
__off__ methods (so to speak).

But if I "aim" a remote at (i.e. "bind" a remote to) another object type,
then the "buttons" (the API, i.e. the methods) will be different.  Only
some types have __on__ and __off__.

We all agree it's on the TV itself that channel changing happens (it's the
TV itself that's mutable -- back to where we started, agreeing above).

Going:

>>> myTV = TV()
>>> myTV.change(6)

is making a mutable object's state mutate.

myTV is not the object itself, it's a name for some object (and not a
container of it either -- an image we don't need).



> I do not get the variable and remote buttons analogy at all. The
> importance of a variable naming a memory *location* with a reference is
> that clearly there can be only one reference at that memory location at a
> time.
>

But once you have that name (what some call a "variable"), there's now so
much more you can do, beyond simply naming.

If S names a string, you can now S.upper() it, and if it's an int, you can
S.__add__ it to something else.

The name (remote) "sprouts buttons" (like off and on) in accordance with
what type it aims at (binds to).

The name has its dot methods and dot attributes, useful for changing that
stuff in memory which actually does the work.



> There is nothing saying with the English word "label" that two different
> objects/places could not have the same naming label slapped on them, so
> relying too heavily on easy English analogies is tricky.
>


How do I take the very same physical post-it, this very one, and affix it
to two different objects at the same time?

How would you draw that?  It seems grammatically challenging.

I suppose one could sort of half-affix it to two different objects and the
same time.  A luggage tag could loop through two suitcase handles.  OK, you
got me there:  the English is ambiguous.

However:  how do five "containers" (known as "variables" in some
narratives) all "contain" the "same" object, which they may be proved to
do, using id(A), id(B), id(C) and so on?  A,B,C,D,E all reference the very
same object.  What's the picture?

How does it help to say these five names of the same thing are "containers"
of that thing?  Why do "buckets" make more sense that "post-its"?

The object itself is a container (like a bucket), sure, in that it likely
has / contains attributes (data), and is either mutable or not.  So I'm
willing to say the object is variable, in the sense of mutable, but that
just grates on the ears of those who want to say "variable" to mean "Python
name".

Names of these objects by be known as "variables" but they are not
containers and they only "vary" in the sense that names, like post-its, may
be affixed to any object of any type.  Integer or steam engine, it won't
matter.

So lets put to rest the idea that A,B,C... all "contain" the same object.
There's no mental picture that's not messy in that case.



>
> In my Hands-on Python Tutorial <http://anh.cs.luc.edu/python/hands-on/3.1>
> I say all data has a type, and I start with immutable objects types.  I say
> initially that a variable is a name used to refer to a piece of data.
>

No problem with any of that.  Or just say we use names to refer to data
(objects).

Who cares about "variables"?  As opposed to what, "constants"?  Do we call
a luggage tag a "variable" just because it tags any suitcase?  I suppose we
could.



> Much later I get to mutable objects, and then the idea of a reference to
> an object is key to understanding.
>

Sounds good too.

remote = TV()   # give me a way to control a TV instance
remote.on()       # now I'm controlling it, using the name (remote)
remote.change_channel(6)  # controlling it more (it being some thing on the
heap)

The remote is controlling something on the heap that may have many names.
When it has no names, it gets garbage-collected.



> I point out that with immutable objects this does not make much
> difference, but when we start dealing with mutable objects, it is important
> to be more precise.  This sequence seems to work fine.
>

Sounds fine to me too.

Tuples may have mutable elements, but are immutable in the sense of having
just those elements (mutable or not, you can't add or remove them).

That's an important discussion, and not "advanced" as the idea of appending
to a list is as familiar as adding an item to a grocery cart.

These concepts are mundane, routine, not even that abstract.  They are
anchored in ordinary language and everyday experience.

OK, I think that's enough reiteration to keep it clear.  Objects do all the
work. Names are a means to that end, in providing the corresponding dot
notation syntax.

Kirby



>
> Andy
>
> Dr. Andrew N. Harrington
>   Computer Science Department
>   Graduate Program Director gpd at cs.luc.edu
>   Loyola University Chicago
>   529 Lewis Towers, 111 E. Pearson St. (Downtown)
>   417 Cudahy Science Hall (Rogers Park campus)
> http://www.cs.luc.edu/~anh
> Phone: 312-915-7982
> Fax:    312-915-7998
> aharrin at luc.edu (as professor, not gpd role)
>
> On Mon, Feb 15, 2016 at 8:58 PM, kirby urner <kirby.urner at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Feb 15, 2016 at 5:23 PM, Carl Karsten <carl at nextdayvideo.com>
>> wrote:
>>
>>> I think the point of this thread is: how important is this subject?
>>>
>>>
>> I don't know that there's a scale of 1-10 answer.  If / when it comes up,
>> as a student question, it becomes important, but also instructors need to
>> explain how a given object may have many names, whereas of we're focused on
>> "containers" how does that look?
>>
>>
>>
>>> I have one of many answers: in my 2 hour 500 line intro to python, it
>>> gets about 60 seconds spent on this 1 line:
>>>
>>> """Other languages have variables; technically, Python doesn't. But it
>>> has something that looks like a var: It has names. So don't call it a var.
>>> For a good explanation of this see
>>> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
>>> """
>>>
>>
>> This is excellent.
>>
>> I was racking my brains where to find visuals like this, specifically
>> showing the buckets versus post-its models.
>>
>> I've added links to my make_links_v2.py and make_links_v3.py @ <guild />
>> [1]
>>
>> This thread was useful for our trains at PDX Code Guild at least, as I'm
>> having philosophical differences with some of my peers regarding the
>> uber-basics and how best to teach them.
>>
>> I've been told repeatedly that code school students will start out *not*
>> knowing what a variable is and my number one most important responsibility,
>> right from the get go, is to introduce the concept.
>>
>> Fine.  But what if the curriculum hard-codes that we should see variables
>> as "containers".
>>
>> Before I lead a boot camp, Python-centric, I want to make sure I'm not
>> shackled to a misinforming presentation I'm not comfortable teaching.  It'd
>> just feel wrong, like I'm lying, to force the "container metaphor".  I
>> needed ammo.
>>
>> By now, thanks to these threads today, I feel well armed in my views that
>> I'm free to avoid said metaphor if I want to.
>>
>> Here's a screen shot of our faculty Slack feed from a few minutes ago:
>>
>> https://flic.kr/p/DduBoA
>>
>> There's enough consensus out there to defend my position.  Yay.
>>
>> What I want to avoid is another instructor insisting on the "variable as
>> container" metaphor to a point where I feel I have to do extra work to undo
>> that picture.
>>
>> Thanks again for the tools, should that come up.
>>
>> Kirby
>>
>> [1]
>> https://www.dropbox.com/home/PDX%20Code%20Guild/Accelerated%20Programming%20%28fork%29
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160215/1d92b005/attachment-0001.html>

From mark.engelberg at gmail.com  Tue Feb 16 04:13:09 2016
From: mark.engelberg at gmail.com (Mark Engelberg)
Date: Tue, 16 Feb 2016 01:13:09 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAPJgG3QXngOK0011niUVqxUXD=hcrpXrdnadx++_fLBSGhtxdw@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
 <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
 <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>
 <CAPJgG3QXngOK0011niUVqxUXD=hcrpXrdnadx++_fLBSGhtxdw@mail.gmail.com>
Message-ID: <CAORbMOO-hGBGLCrd1Q1DfKpTDv_BqAO_2+T04Wik83RiMU0=GQ@mail.gmail.com>

First, add me to the chorus of people saying that using the term "variable"
to categorize mutable objects versus immutable objects is counter to the
way every programmer uses and understands the term "variable" to mean a*
name *that can take on multiple values over the lifetime of a program.
Sounds like you've already been convinced about this by the others, so I
won't belabor that point here.

So let's move on to the topic of "containers" versus "labels" as a metaphor
for variables.  I have used both, and I think both work equally well with
students (but we can do better, more on that in a moment).  Your main
argument against containers is that it goes against real-world intuition to
have one value in two containers.  This is easy enough to rectify.  Each
container is designed to hold a piece of paper with enough space to write
64 0's and 1's.  Putting something in a container simply means we write the
64 0's and 1's that describe where to find the object in the computer's
memory -- an address -- and put that piece of paper in the container.  No
student has a problem with the idea of two containers, each containing
their own piece of paper that happens to have the same number written on
it.  Arguably, the "containers of addresses" model is more precise than the
label model.

But we can do better than both the container and label model.

The clearest teaching model: A variable is simply an entry in a dictionary.

First, we need to talk about what it means for the Python interpreter to
interpret or "evaluate" an expression.
When I type x+y at the interpreter, what does that mean?  How is that
evaluated?  Well, it's completely meaningless unless we know what the value
of x and y are.  Python keeps around a dictionary/table that stores
associations between names and values.

When I say x=2, all this means is that I'm adding an entry (or modifying an
existing entry) in the main (global) dictionary that says x is now
associated with 2.
When I evaluate an expression like x+y, Python looks up the values for x
and y in its dictionary.

Right-hand sides of assignments are always evaluated first before an entry
is put in the dictionary.  So z=x first evaluates x, by looking it up
(right now, it's 2) and then adding an entry in the dictionary between z
and 2.  (By using this more precise mental model, students now won't get
tripped up by things like x=2, z=x, x=3 and thinking that somehow z has
changed).

Every function keeps around its own dictionary of name/value associations.
When evaluating expressions inside a function, Python first tries to look
up the name in the function's dictionary, and if not found there, works its
way outward to the global dictionary (for beginners, there aren't likely to
be more than two levels, so you can simplify this discussion a bit for
beginners by talking about only two levels until you get to nested
functions).  When Python evaluates an assignment inside a function, it
evaluates the right-hand-side using the rule just given, and then creates a
new entry in the function's dictionary.  (By using the more precise mental
model, we've just explained some of the most complex intricacies of lexical
scoping and how it behaves in Python, including a lot of surprising gotchas
where people think they are assigning a global variable, but are actually
just creating and assigning a new local variable.)

I'm not opposed to giving simplified mental models to beginners and then
later saying, "I lied before.  It's really more complicated than that."
But only if it's necessary.  In this case, it's not.  The dictionary model
is more accurate, and no more difficult for students to understand.  It's
sort of like the label model, but more detailed because it tells us where
these connections from labels to values actually live.  This allows
students to use their intuition they've developed from working with
Python's dictionary data structure in order to understand how name/value
associations are created, modified, and accessed.  It provides far more
context for understanding scoping.  So I advocate for using this model from
the start.

The difference between the dictionary model and the label model is subtle,
but it does require you to use different visual images to explain what is
going on.  Instead of showing objects put into boxes, or showing post-its
attached to objects, when you step through a program on your whiteboard for
the students, start off by drawing a big blank "piece of paper" off to the
side labeled "dictionary".  As you step through the program, write in new
name/value entries on the dictionary.  When you reassign a variable, find
that name in the dictionary and erase the value that's there, and write in
the new value.  When you enter a function, draw another "piece of paper"
near the function to contain its name/value associations.  Give them this
clearer visual imagery as you step through the program -- you'll be glad
you did.

When you want to get into mutability/immutability, instead of writing the
actual value next to the name on the dictionary page, write the value at
some random location on the board (you can draw a cloud to represent the
computer's memory, and write the value in that area), and then the
dictionary just contains the name and next to it an arrow to the value out
in the memory (or use the address metaphor I described above if you
prefer).  This helps understand how two names can connect to the same
object.

Hope this helps,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160216/e556cf39/attachment.html>

From mark.engelberg at gmail.com  Tue Feb 16 04:32:43 2016
From: mark.engelberg at gmail.com (Mark Engelberg)
Date: Tue, 16 Feb 2016 01:32:43 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAORbMOO-hGBGLCrd1Q1DfKpTDv_BqAO_2+T04Wik83RiMU0=GQ@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
 <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
 <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>
 <CAPJgG3QXngOK0011niUVqxUXD=hcrpXrdnadx++_fLBSGhtxdw@mail.gmail.com>
 <CAORbMOO-hGBGLCrd1Q1DfKpTDv_BqAO_2+T04Wik83RiMU0=GQ@mail.gmail.com>
Message-ID: <CAORbMOMHj8DuGX+oLfzZeNp=2hD7szZYBMh4NiG1a+p6mKYwuw@mail.gmail.com>

Advanced students can gain a much deeper understanding of variables by
writing an interpreter themselves.

This free course on udacity will show advanced students how to write a
basic Javascript interpreter in Python:
https://www.udacity.com/courses/cs262
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160216/65e83989/attachment.html>

From kirby.urner at gmail.com  Tue Feb 16 12:52:25 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 16 Feb 2016 09:52:25 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAPJgG3Q2EJzgPG2N+O966kazs+o=y2_tFTfkj-eMn21Y0OpzZQ@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
 <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
 <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>
 <CAPJgG3QXngOK0011niUVqxUXD=hcrpXrdnadx++_fLBSGhtxdw@mail.gmail.com>
 <CAORbMOO-hGBGLCrd1Q1DfKpTDv_BqAO_2+T04Wik83RiMU0=GQ@mail.gmail.com>
 <CAPJgG3Q2EJzgPG2N+O966kazs+o=y2_tFTfkj-eMn21Y0OpzZQ@mail.gmail.com>
Message-ID: <CAPJgG3TOLZncMAYVrhrHTt8PEaNr8-ymheBv4-0gZT1au7Know@mail.gmail.com>

I'm noticing that postings with edu-sig as one among several take longer to
show up in the archives.

I'm going to not reply-all in future and just use edu-sig for its mail
reflector powers.  That should make the moderator's job a little easier.

Kirby



On Tue, Feb 16, 2016 at 9:33 AM, kirby urner <kirby.urner at gmail.com> wrote:

<< SNIP >>


>
>
> One imperils the precious new freedoms pioneered by VHLLs when
> reintroducing all the cruft.
>
> The nitty gritty of Von Neumann architecture is not part of the mental
> model we may dispense with for the time being.
>

"not part of the mental model [and so] we may dispense with [it] for the
time being".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160216/08095051/attachment.html>

From daniele.gianni at gmail.com  Tue Feb 16 17:45:40 2016
From: daniele.gianni at gmail.com (Daniele Gianni)
Date: Tue, 16 Feb 2016 23:45:40 +0100
Subject: [Edu-sig] [CfP] 5th IEEE Track on Collaborative Modeling and
 Simulation (Comets 2016) **** Submission Deadline Extended ****
Message-ID: <CAOCNFM4E1FknbWDYhGr-Le_hBeB0_CkFfUzw0QcqfRp6Bq-etA@mail.gmail.com>

*************** Submission Deadline Extended **********************

(Please accept our apologies if you receive multiple copies of this
message)

#################################################################
                       IEEE WETICE 2016
     5th IEEE Track on Collaborative Modeling and Simulation
                        (Comets 2016)

             in cooperation with (approval pending)
                         INCOSE Italy
               MIMOS (Italian Association for M&S)

                       CALL FOR PAPERS

#################################################################

June 13-16, 2016 - Paris (France)
http://www.sel.uniroma2.it/comets16

#################################################################
# Papers Due: February 25, 2016 ***** Extended ******
# Accepted papers will be published in the conference proceedings
# by the IEEE Computer Society Press and will be submitted for
# indexing through INSPEC, Compendex, Scopus, Thomson Reuters,
# DBLP, Google Scholar and EI Index.
#################################################################

Modeling and Simulation (M&S) is increasingly becoming a central
activity in the design of new systems and in the analysis of
existing systems because it enables designers and researchers to
investigate systems behavior through virtual representations. For
this reason, M&S is gaining a primary role in many industrial and
research fields, such as space, critical infrastructures,
manufacturing, emergency management, biomedical systems and
sustainable future. However, as the complexity of the
investigated systems increases and the types of investigations
widens, the cost of M&S activities increases for the more
complex models and for the communications among a wider number and
variety of M&S stakeholders (e.g., sub-domain experts, simulator
users, simulator engineers, and final system users). To address
the increasing costs of M&S activities, collaborative
technologies must be introduced to support these activities by
fostering the sharing and reuse of models, by facilitating the
communications among M&S stakeholders, and more generally by
integrating processes, tools and platforms.

Aside from seeking applications of collaborative technologies to
M&S activities, the track seeks innovative contributions that
deal with the application of M&S practices in the field of
collaborative engineering platforms. These platforms are continuously
becoming more complex, and therefore their design requires
systematic approaches to meet the required quality of
collaboration. This is important for two reasons: to reduce
rework activities on the actual collaborative environment, and to
maximize the productivity and the quality of the process the
collaborative environment supports. M&S offers the methodologies
and tools for such investigations and therefore it can be used to
improve the quality of collaborative environments.

A non-exhaustive list of topics of interest includes:

* collaborative requirements modeling
* collaborative environments for M&S
* collaborative Systems of Systems M&S
* business process modeling for collaborative environments
* agent-based M&S
* collaborative distributed simulation
* collaborative component-based M&S
* net-centric M&S
* web-based M&S
* model sharing and reuse
* model building and evaluation
* modeling and simulation of business processes
* modeling for collaboration
* simulation-based performance analysis of collaborative engineering
platforms
* model-driven approaches for collaborative engineering
* domain specific languages for collaborative M&S
* databases and repositories for M&S
* distributed virtual environments
* virtual research environment for M&S
* collaborative DEVS M&S
* multi-method M&S

To stimulate creativity, however, the track maintains a wider
scope and invites interested researchers to present contributions
that offer original perspectives on collaboration and M&S.

+++++++++++++++++++++++++++++++++++
On-Line Submissions and Publication
+++++++++++++++++++++++++++++++++++

CoMetS'16 intends to bring together researchers and practitioners
to discuss key issues, approaches, open problems, innovative
applications and trends in the track research area.

Papers should contain original contributions not published or
submitted elsewhere. Papers up to six pages (including figures,
tables and references) can be submitted. Papers should follow the
IEEE format (http://www.ieee.org/conferences_events/conferences/
publishing/templates.html). All submissions should be submitted
in PDF format and will be peer-reviewed by at least three program
committee members.

Accepted papers will be included in the proceedings and
published by the IEEE Computer Society Press.
Please note that at least one author for each accepted paper should
register to attend WETICE 2016 (http://www.wetice.org) to have the
paper published in the proceedings.

Interested authors and participants may contact the organizers for
expression of interests and content appropriateness at any time.

Papers and posters can be submitted in PDF format at the conference
submission site (https://www.easychair.org/conferences/?
conf=wetice2016), by selecting the ?Collaborative Modeling and
Simulation? track.

+++++++++++++++
Important Dates
+++++++++++++++

* Submission Deadline: February 25, 2016 ***** Extended *****
* Notification to authors: March 28, 2016
* Camera Ready to IEEE: April 11, 2016
* Conference date: June 13-16, 2016

+++++++++++++++++
Program co-chairs
+++++++++++++++++

Andrea D'Ambrogio, University of Roma TorVergata, Italy
Gregory Zacharewicz, University of Bordeaux, France
Daniele Gianni, Guglielmo Marconi University, Italy

*** Contact Information ***
Andrea D'Ambrogio (track co-chair)
Email: dambro at uniroma2.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160216/a26d80a9/attachment.html>

From kirby.urner at gmail.com  Thu Feb 18 14:53:48 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 18 Feb 2016 11:53:48 -0800
Subject: [Edu-sig] what is a "variable" in Python?
In-Reply-To: <CAM=hmRNP4GTEdj-jcY3XVQ_fcR4Tkd07E7Nvkv_GEQgAsEN+Ow@mail.gmail.com>
References: <7.0.1.0.2.20160215151924.04e12b50@skylit.com>
 <CAL9=h-PcBmXKPpz3qQ5_zL9zHJA5HsjWgT73E0LO5XZA2V-LkA@mail.gmail.com>
 <CAPJgG3STKfS+VLPL4_WBb0508Wcq+zay4Pfkn4AkZtjxao4Z3w@mail.gmail.com>
 <CADmzSSjKbtZKUQODBOqzPV9Yhrjh0XE5QtziF++s0aFzb0bFNA@mail.gmail.com>
 <778769f90e3d4d02891777617a04e0a1@MBXLS1.adms.luc.edu>
 <CAOaxTEJO2g=i2oAnHLMmbCkbyLATB-dZex3r-d6bdKvkngo3KQ@mail.gmail.com>
 <CAPJgG3QXngOK0011niUVqxUXD=hcrpXrdnadx++_fLBSGhtxdw@mail.gmail.com>
 <CAORbMOO-hGBGLCrd1Q1DfKpTDv_BqAO_2+T04Wik83RiMU0=GQ@mail.gmail.com>
 <CAPJgG3Q2EJzgPG2N+O966kazs+o=y2_tFTfkj-eMn21Y0OpzZQ@mail.gmail.com>
 <CAPJgG3TOLZncMAYVrhrHTt8PEaNr8-ymheBv4-0gZT1au7Know@mail.gmail.com>
 <CAM=hmRNP4GTEdj-jcY3XVQ_fcR4Tkd07E7Nvkv_GEQgAsEN+Ow@mail.gmail.com>
Message-ID: <CAPJgG3QLC5LXNSq==mdA6TmqyRtKRNK=YWEF6f7RQYJqPwaydw@mail.gmail.com>

On Thu, Feb 18, 2016 at 11:17 AM, Al Sweigart <al at inventwithpython.com>
wrote:



> Reference issue aside, I think the container works as a mental model. The
> problem with the tag/label model is that if you think of the variable
> `spam` as being attached to the value 42 and `eggs` as being attached also
> to 42, it brings up the confusing idea: why do you have separate 42s if you
> could just put both variable tag/labels on one 42? Where does this 42
> exist? Do all possible integers and strings just exist "out there", waiting
> to have a tag/label attached to them?
>

Would "yes" be a wrong answer?

>>> spam = eggs = 42
>>> id(spam) == id(eggs)
True

Two labels (two names), one thing (object, e.g. 42).

But no, they don't always all exist already because the types are the
birthing sources i.e. you need int, str, dict, tuple and so on to populate
the space with actual instances.  spam = 42 is short for spam = int('42',
10), where we're less fussy about base in the general sense.

If you *can* jettison containers, and just stick with pieces of paper, it's
lighter weight, conceptually.  I encourage the bucket kickers.  Hah hah.
As in "kicking the habit" of thinking "variables are buckets".  That's
early stages something not-so-healthy around Python, could be fine if
you're smoking C. :-D


Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160218/42b46034/attachment.html>

From kirby.urner at gmail.com  Thu Feb 25 15:05:04 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 25 Feb 2016 12:05:04 -0800
Subject: [Edu-sig] frustrations attempting to join edu-sig?
Message-ID: <CAPJgG3TJybjEUUEgetfay4jZDg2FbEPO1SFqy_Zhg59_d7at+Q@mail.gmail.com>

Do we have a listowner here?  On the behest of this would-be poster I'm
sharing about his attempt to join our discussions.

Kirby
FYI.


---------- Forwarded message ----------
From: Aivar Annamaa <aivar.annamaa at ut.ee>
Date: Thu, Feb 25, 2016 at 7:51 AM
Subject: Writing to Python Edu-Sig mailing list
To: kirby.urner at gmail.com


Hi, Kirby!

I noticed you are an active member in Python Edu-Sig mailing list. I joined
the list and tried to write to it several times but seems that my letters
are just vanishing. I also wrote to edu-sig-owner at python.org and
wilson at visi.com (couple of weeks ago) but got no response.

Could you please notify the right persons that there seems to be problem in
accepting new members into the list? Maybe you can forward my letter to the
list?

In case you think my e-mails were discarded because they contained spam,
here's what I wanted to discuss:

* There's a Python type checker MyPy (http://mypy-lang.org/) based on PEP
484. I wanted to ask, whether someone has any experience in using type
annotations in teaching Python.
* I have created a Python IDE for beginners (http://thonny.cs.ut.ee/) and I
believe people in this mailing list would be interested in it.

best regards,
Aivar Annamaa
University of Tartu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160225/98dcb89c/attachment.html>

From kirby.urner at gmail.com  Fri Feb 26 09:55:33 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 Feb 2016 06:55:33 -0800
Subject: [Edu-sig] 1-2-3 testing (forwarded announcement)
Message-ID: <CAPJgG3S5Qt8x36tyj-xG0+akzTH9Lk-0Z56zGzxhyzFgc_FCwQ@mail.gmail.com>

From: Ted Boulou <tboulou at somtou.com>
Date: Fri, Feb 26, 2016 at 4:55 AM
Subject: How we are using a Python-powered wooden-made Pi-based device to
help micro-entrepreneurs in Senegal
To: python-announce at python.org


Hello sir,madam,

I am Ted, CEO of a start-up based in Senegal that has built the Somtou.

The Somtou is a *wooden-made* tablet-like device based on a *Raspberry
Pi* running
a *Python kivy-based software* that helps the micro-entrepreneurs in Africa
and in emerging markets manage easily their businesses.

We use 3D printing, CNC combined with pure craftsmanship to build the
Somtou.

I have enclose a small presentation.

You can check our website www.somtou.com

We will be delighted to discuss forward,
BOULOU
*Founder and Elephant*

Mob : (221) 76 644 50 25
@ : tboulou at somtou.com <tboulou at poeyek.com>
skype : ted.boulou
*Visit us : www.somtou.com <http://www.somtou.com/>*
--
https://mail.python.org/mailman/listinfo/python-announce-list

        Support the Python Software Foundation:
        http://www.python.org/psf/donations/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160226/f8cc26bb/attachment.html>

From funcalculus at gmail.com  Thu Feb  4 18:44:39 2016
From: funcalculus at gmail.com (Peter Farrell)
Date: Thu, 04 Feb 2016 23:44:39 -0000
Subject: [Edu-sig] Outreach to High Schools
Message-ID: <CAN=3tEjG7tuj7bjObg80OKVHX3awV7w5TKYZ1FcDH9P_E-uM2A@mail.gmail.com>

Hi, Edu-Sig,

I'm a long-time reader and first time poster. I just listened to a podcast
with Jessica McKellar saying the PSF Is interested in getting Python
adopted by more high schools and colleges. I've done a lot of work to that
end.

As a math teacher I learned some coding and passed it on to students. I've
held Python and Pi meetups here in the Bay Area. Last year I collected my
Python explorations ranging from basic turtle geometry to calculus and the
result is *Hacking Math Class with Python <http://www.farrellpolymath.com/>*,
available as a pdf on my website and coming soon to an online bookstore
near you. I've also posted dozens of tutorial videos on my YouTube channel,
mostly on doing math using Python.

I would love to teach Python to STEM teachers, and I'm asking if anybody
knows of a contact person like a district technology director or
coordinator. I think Python could revolutionize math instruction since it's
revolutionizing everything from data science to web development to modding
Minecraft.

Thank you in advance!

Peter Farrell
San Mateo, CA
farrellpolymath
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160204/88af863d/attachment.html>

From funcalculus at gmail.com  Mon Feb 29 10:53:39 2016
From: funcalculus at gmail.com (Peter Farrell)
Date: Mon, 29 Feb 2016 07:53:39 -0800
Subject: [Edu-sig] Project Euler with Python
Message-ID: <CAN=3tEhS2XAiAxJyjHfrHfVaQjkGUs_zuc6BR59JycNP5+gpJA@mail.gmail.com>

Hello to the Education group! Thought you might be interested in some mathy
Python stuff I've been doing lately.

I took my Coder School students through a lesson from my book, creating
fractal trees using recursion, and a few of them finished that with enough
time to look at a use of recursion to do something other than draw stuff.
We looked at Project Euler problem #18 <https://projecteuler.net/problem=18>.
We used the same recursive method we used to make trees to search through a
tree of numbers. Here's a recursive function for finding the maximum path
through the triangle:

def maxPath(r,c):
    if r == 14: #if it's in the last row
        return cell[r][c] #return the value of that cell
    else: #return the cell + the max of the maxPaths of the lower two cells
        return cell[r][c] + max(maxPath(r+1,c),maxPath(r+1,c+1))

I'm still tickled that recursive functions work. I picture it as a recipe
for baking a loaf of bread containing the step "Bake a loaf of bread."
Anyway, it worked!

Problem #67 <https://projecteuler.net/problem=67> is the same idea but with
a much bigger array. My method didn't scale well from 15 rows to 100 but
the site predicted that and hinted that "a clever method is needed." I
thought of a better method (clever? idk), and it worked on problem 18, so I
copied the big honking array into a txt file and changed the parameters to
handle 100 rows. Got the right answer in 4 hundredths of a second. Let me
know if you're dying to see that solution, too.

Maybe a Project Euler-based math course or eBook is in order. I'm so
fascinated by the mathematical nature of the step from brute force to more
elegant solutions and I'm sure there are lots of common factors (pun
intended) that could serve as topics of discussion. It's interesting to
make Python tools that seem to be needed repeatedly on PE like a prime
number generator, a function to create a list of the permutations of the
digits of a number, and so on.

I'm interested in any feedback the group has.

Peter Farrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160229/8200f0bd/attachment.html>