Experiences/guidance on teaching Python as a first programming language

[Chris Angelico]

On Wed, Dec 18, 2013 at 12:33 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote:
>
>> There's very few mysteries in C.
>
> Apart from "What the hell does this piece of code actually do?". It's no
> coincidence that C, and Perl which borrows a lot of syntax from C, are
> the two champion languages for writing obfuscated code.

I thought APL would beat both of them, though you're right that the
International Obfuscoted Python Code Contest would be a quite
different beast. But maybe it'd be just as viable... a competent
programmer can write unreadable code in any language.

> And "What does 'implementation-specific undefined behaviour' actually
> mean in practice?", another common question when dealing with C.

You mean like mutating locals()? The only difference is that there are
a lot more implementations of C than there are of Python (especially
popular and well-used implementations). There are plenty of things you
shouldn't do in Python, but instead of calling them
"implementation-specific undefined behaviour", we call them
"consenting adults" and "shooting yourself in the foot".

> And most importantly, "how many asterisks do I need, and where do I put
> them?" (only half joking).

The one differentiation that I don't like is between the . and ->
operators. The distinction feels like syntactic salt. There's no
context when both are valid, save in C++ where you can create a
"pointer-like object" that implements the -> operator (and has the .
operator for its own members).

>> You never have to wonder what the
>> lifetime of an object is,
>
> Since C isn't object oriented, the lifetime of objects in C is, um, any
> number you like. "The lifetime of objects in <some language with no
> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously true
> statement.

Lifetime still matters. The difference between automatic and static
variables is lifetime - you come back into this function and the same
value is there waiting for you. Call it "values" or "things" instead
of "objects" if it makes you feel better, but the consideration is
identical. (And in C++, it becomes critical, with object destructors
being used to release resources. So you need to know.)

>> or be mystified by which of the 7 signatures
>> of Foo.foo() are going to get called,
>
> Is that even possible in C? If Foo is a struct, and Foo.foo a member, I
> don't think C has first-class functions and so Foo.foo can't be callable.
> But if I'm wrong, and it is callable, then surely with no arguments there
> can only be one signature that Foo.foo() might call, even if C supported
> generic functions, which I don't believe it does.

Well, okay. In C you can't have Foo.foo(). But if that were Foo_foo(),
then the point would be better made, because C will have just one
function of that name (barring preprocessor shenanigans, of course).
In C++, the types of its arguments may affect which function is called
(polymorphism), and the dot notation works, too; but C++ does this
without having first-class functions, so that part of your response is
immaterial. In C++, Foo.foo() will always call a function foo defined
in the class of which Foo is an instance. Very simple, and static type
analysis will tell you exactly which function that is. Things do get a
bit messier with pointers, because a function might be virtual or not
virtual; C++ gives us the simple option (non-virtual functions) that
most high level languages don't (C++'s virtual functions behave the
same way as Python member functions do).

ChrisA