Comments on my "Python Introduction" slides
Miki Tebeka
tebeka at cs.bgu.ac.il
Tue Aug 26 06:18:21 EDT 2003
Hell Paul,
> However, and not knowing your audience, I wonder if the slides are a bit
> advanced (but obviously they are probably not meant to stand alone from
> your talk, and your purpose might be to _wow_ your audience).
Yap. I'll bee it up while I talk.
> For example, will people really understand how useful and powerful and
> easy to use dictionaries are [a key feature of Python] by just saying
> they are like a hash table? You have an example of a dictionary in use
> in "unique" but in the example doesn't add something into the dictionary
> in the flow of the text of the program until after the test -- a
> perfectly good way to implement it, but perhaps harder to follow
> initially for some people (who may be asking where does the data come
> from when they get to the test.). Also, since you just set the value to
> true, it doesn't quite capture how most dictionaries are typically used
> (to store key value pairs). I'd say another slide on dictionaries might
> be warranted with a simpler better example, to preceed the "unique"
> example one you have there. Somethign blah like just putting names and
> email addresses together.
A good point. I'll try adding one.
> Also, since one a pracical basis some fraction of your audience is going
> to recoil at the significant white space, you might have a slide on this
> (maybe in the middle, or after your first example) and how it is not a
> problem in practice, and in fact promotes maintainability and prevents
> some bracing style clashes. For me (having used Occam earlier, which
> also uses significant white space), significant white space for block
> delimiting is one of Python's best features. You might as well confront
> the controversy head on somehow (like quotes from this newsgroup from
> converts to it?) I can also see an argument for not bringing the subject
> up as that might scare people off, but since you have a chance to bring
> it out in the open in a controlled way sounding favorable to Python, and
> you know it will be an issue for people coming from C, it might be best
> to just deal with it.
You're right. I think I'll talk about it without a slide. But I need
to get prepared. I think ESR's article has some stuff in it.
> Obviously, you only have so much time for a talk, so you have to
> prioritize, and maybe there isn't enough time for two more slides. But,
> I think if you had to drop two, I'd drop the "generators" and "fibs
> geenrator" example. You may well lose a lot of your audience there
> anyway (as while useful, the continuation concept is somewhat abstract
> and advanced).
I think Python's generators are easyer to understand than Scheme
continuations (which I don't fully grasp yet :-). It's a very
powerfull idiom which is used a lot in 2.3 (see itertools module)
> Also, the "Quick One" items might easily include a word or two on the
> topic, i.e. "Quick One: Files" or "Quick One: fibs" for reference.
OK.
> Also "Not In Standard Library" might be changed to "Free Third-party
> Addons" to sound a little nicer (otherwise people might think it is a
> complaint).
OK.
> You might also rename your "Development Methodology" slide as "Will it
> be fast enough?" or something like that ("Developing for speed?") and
> reference programmer time vs. execution time, since I expected that
> slide otherwise based on the title to reference Extreme Programming vs.
> Waterfall Development models or some such approaches.
OK.
> Having said all that (and none of those are major problems in the
> context of a talk where you continually monitor the audience's
> understanding and adapt your comments), I think the use of complete
> small program examples (e.g. du, fibs, etc.) in your tutorial was a
> great choice to help people grasp the language.
>
> So, overall, good job!
Thanks.
Thanks for you help.
Miki
More information about the Python-list
mailing list