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