Experiences/guidance on teaching Python as a first programming language

[Steven D'Aprano]

On Wed, 18 Dec 2013 13:11:58 +1100, Chris Angelico wrote:

> 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(). 

Hah, well according to Paul Smith's example code you can. So either:


- it's possible to be an experienced C programmer and still have 
fundamental gaps in your knowledge about basic concepts like dotted 
function calls;

- or Paul's sample code was not what he claimed it to be;

- or maybe the whole thing is undefined and we're all right! C both does 
and doesn't allow Foo.foo() function calls, *sometimes at the same time*.



-- 
Steven