tough-to-explain Python

[Simon Forman]

On Jul 7, 4:04 pm, kj <no.em... at please.post> wrote:
> I'm having a hard time coming up with a reasonable way to explain
> certain things to programming novices.
>
> Consider the following interaction sequence:
>
> >>> def eggs(some_int, some_list, some_tuple):
>
> ...     some_int += 2
> ...     some_list += [2]
> ...     some_tuple += (2,)
> ...
>
> >>> x = 42
> >>> y = (42,)
> >>> z = [42]
> >>> eggs(x, y, z)
> >>> x
> 42
> >>> y
> (42,)
> >>> z
> [42, 2]

You have transposed some_list and some some_tuple. I.e. you should be
calling eggs(x, z, y).

> How do I explain to rank beginners (no programming experience at
> all) why x and y remain unchanged above, but not z?

You don't. Rank beginners don't have enough background knowledge to
grok that code.

Why would you even tell the poor bastards about "+=" before they were
comfortable with (python's style of) function calls, immutable
integers, mutable lists and immutable tuples?

Let them use "x = x + y" until they have enough knowledge to
understand "augmented" assignment.

Syntax matters (I mean general order of things, not linguistic
syntax.)  Making an omelette requires putting eggs in a pan and
cracking them, but not in that order.

> Or consider this one:
>
> >>> ham = [1, 2, 3, 4]
> >>> spam = (ham,)
> >>> spam
> ([1, 2, 3, 4],)
> >>> spam[0] is ham
> True
> >>> spam[0] += [5]
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
> >>> ham += [5]
> >>> spam
>
> ([1, 2, 3, 4, 5, 5],)
>
>
>
> What do you say to that?

I say, "Don't use augmented assignment with indexed tuples."

Seriously, python's augmented assignment is almost magical. I think
you're just making trouble for yourself and your students if you
introduce it too early.

I get python pretty well (if I say so myself) but I wouldn't know how
to explain:

In [1]: def foo(a_list):
   ...:     a_list = a_list + [5]
   ...:
   ...:

In [2]: n = []

In [3]: foo(n)

In [4]: n
Out[4]: []

In [5]: def bar(a_list):
   ...:     a_list += [5]
   ...:
   ...:

In [6]: bar(n)

In [7]: n
Out[7]: [5]


It's "Just The Way It Is". Freakin' magic, man.

> I can come up with much mumbling about pointers and stacks and
> heaps and much hand-waving about the underlying this-and-that, but
> nothing that sounds even remotely illuminating.
>
> Your suggestions would be much appreciated!

Frankly, I'm of the impression that it's a mistake not to start
teaching programming with /the bit/ and work your way up from there.
I'm not kidding. I wrote a (draft) article about this: "Computer
Curriculum" http://docs.google.com/View?id=dgwr777r_31g4572gp4

I really think the only good way to teach computers and programming is
to start with a bit, and build up from there. "Ontology recapitulates
phylogeny"

I realize that doesn't help you teach python, but I wanted to put it
out there.