On Feb 5, 2010, at 9:31 PM, kirby urner wrote:
> What I'm not seeing here is any plans to venture into user-defined types
> i.e. rolling your own classes.
I am indeed tempted into user-defined types. I actually teach OO Python in my
App Engine course because it is necessary there. And Think Python has a nice
chapter. But my problem is find a use case that drives me there in "exploring
data" - I see using objects all over the place - but making your own does not
yet feel part of the data narrative.
> That's maybe a line you draw between professional programmers and
> people who need to use computers a lot?
Right - and the other fun idea is that if "Python for Informatics" is the first
book, then "Think Python" is the second book. In a second book (which feels
very similar to the first book) you learn how all this stuff "works".
I see in my crazy brain - a whole series of "Think Python" based books that
feed into one another, all open content, and CC-BY-SA licensed all sharing
basic text where needed.
Pure Intro books:
Learning Math with Python
Exploring Data with Python
... ???
The middle book:
Think like a Computer Scientist in Python
The More advanced books:
Web Programming in Python
Game Programming in Python
Building Graphical Tools with Python
The key is that the books could specialize on their topics and not over-teach
in any of the books. I know for example that you like to bring OO in for math
- I don't think that is necessary (we can debate this forever :) ). I would
like to see a Python for math that actually taught Math - not teaching Python
though math. They can learn Python in the second course with "Think Python"
> The text reads like a gentle on-ramp to "core Python" at the moment,
> i.e. it's a very clear step by step intro. So my prejudice as a reader
> is to think defining classes is just around the corner.
Yes - it would be the next chapter.
> I think there's a big "aha!" in Python when you've been using
> dot notation to access the methods of built-in types, e.g. strings,
> and then start to see how you're just hitting against pre-supplied
> class definitions.
Yes - and I love this - but the timing in the narrative must be right. It
cannot be a trap door - as much as we like it. I have found in my App Engine
course if I teach OO one week too early, I lose the students. The pattern I
now use successfully in my App Engine course is to make them use a real object
with self and everything:
class LogoutHandler(webapp.RequestHandler):
def get(self):
....
And the *next week* teach them classes - just using strings and dictionaries
does not produce sufficient curiosity to learn classes. A rich extension
example with good pictures is the right preparation for a intro to classes -
particularly if I keep saying "This syntax is a little new and we will explain
it next week - just use it for now." instead of saying - "You must learn this
now even though it is painful because next week we will be assuming this as a
pre-requisite skill".
> Given how some of the library stuff involved with screen scraping
> might involve subclassing, maybe you're thinking to work it in under
> networked applications or one of those i.e. you have your wily ways.
Really? Send me an example - I will work it in. My thought for that chapter
was to hack it as strings - where should I look for a better example? I ma not
an expert on this stuff and learn new things all the time. Part of the fun of
remixing Thin Python was learning a few new tricks along the way from Allen and
Jeff.
/Chuck
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
