I'm on Safari On-Line sampling: Introduction to Python by Jessica McKellar O'Reilly Media, Inc., 2014
a multi-hour video series. I enjoy and value getting ideas from other Python instructors. I'm scheduled to start a new round myself this very evening. What's standing out for me is how often Jessica uses the phrase "just like in math class" or "as you'd expect from math class". Exactly, reminding viewers of "math class" is as bridge to previous relevant experience for most, though not all. "Using Python as a calculator" is a standard on-ramp since Guido's original tutorial. I do that too. I bet most of us do. We start in a REPL. I appreciate that Jessica starts using type( ) immediately, in the first few minutes, at first to distinguish type(1) from type(1.0) to tease apart ints and floats. Instilling a sense of objects being of various types is going to help students think like computer scientists and understand the deep grammar of Python better. I also tend to introduce dir( ) and help( ) almost immediately, to give a sense of the built-in environment and how to inspect it. Jessica wants to covers int, float, str and bool then start diving in to control structures right away, with if, elif, else and comparison operators (==, >=, < etc.). We're doing if statements in the REPL within the first 30 minutes. I'm also prone to introduce the words "callable" and "name" early on, and discussing how we distinguish between callable and not-callable names. callable() itself is a built-in function: >>> type(callable) <class 'builtin_function_or_method'> Partly why I make this distinction is when using type( ) and str( ), I'm a bit leery of calling str "a function" to often. That's bleeping over an important distinction is it not? It's a callable for sure: >>> str(1) '1' >>> callable(str) # does it "eat"? True and yet... >>> type(str) <class 'type'> >>> type(print) # another callable to share early <class 'builtin_function_or_method'> In other words, str( ) is a callable but not really a builtin function. Like dict, list, int, float... it's the name of a type. When one calls a type directly by name (not one of its methods), we're actually giving birth to a new instance of that type. Functions aren't necessarily like that. They may return anything, of any type, including None. When it comes to laying a foundation, I find it aids understanding to introduce "callables" as a super-set of "names that may be called," inside of which we have "functions" and "types" as example members. On the other hand, this is a fine point, not to be dwelt on but spiraled back to, especially when keyword "class" is introduced. I think Jessica's approach, of glossing over this distinction in a first pass, is totally viable and realize the many delicate trade-offs as "too much too soon" may result in a sense of overwhelm. Finally, I like to emphasize the word "name" over "variable" as I find it important to shake off any mental imagery of a variable as "like a box", which imagery teachers of other languages tend to find useful. Using the word "name" helps to break the hold of "container" which is helpful for understanding how assignment works. Like Steve Holden, another Python teacher I've seen in action a few times, I like to setup a "namespace and object space" distinction, with names pointing to objects. Object space is also "the heap": https://flic.kr/p/DQb8t6 I think it's time to do some new drawings. :-D Kirby
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
