On Friday, May 29, 2015 at 9:32:06 PM UTC+5:30, Mike Driscoll wrote: > Hi, > > I've been asked on several occasions to write about intermediate or advanced > topics in Python and I was wondering what the community considers to be > "intermediate" or "advanced". I realize we're all growing in our abilities > with the language, so this is going to be very subjective, but I am still > curious what my fellow Python developers think about this topic.
[I will assume that this question makes sense in the context of introducing someone (say beginner/learner/noob/etc) to the language] The zen of python makes a subtle distinction between complex and complicated. The answers seem to suggest that people are taking the complicated for the complex. So at the risk of being simplistic (or glib) let me give a definition and a fact: Def: Complex is an 'act of God' Complicated is a slip of man Fact: Programming languages (like programs) are made by humans... who err. So while the err-ors of programmers are only too well-known and spelt 'bugs' we dont spend enough time on language-bugs. In a teaching context this only does injustice to the student because the learner -- typically a kid -- suffering something or other and wondering "Am I not fit for this?? Its so hard!" etc may only need a simple: "Yeah the language designer goofed of on that one" Trivial example: C originally had only & | for both bitwise and logical operators. Later the shortcircuit operators && || were added and kept adjacent in the precedence table. MISTAKE. The bitwise operators are conceptually arithmetic not logical, in that x & MASK == MASK can make sense only one way. C makes sense of it the other way. And so... The most useful, honest line for a teacher to take is: C has goofed on that one... So you need to parenthesize that IOW the beginner is not wrong in writing x & MASK == MASK It is C that is wrong in choosing a meaningless parse of that Now in all fairness python has less gotchas than C but it has its share. So to my mind Steven's "iterators and generators" as intermediate represents no so much an inherent complexity of the subject as an unfortunate complication from sub-optimal design. I would put generators as basic; iterators as intermediate. The generator def foo(): yield 1 yield 2 yield 3 is 'just' the list [1,2,3] + laziness - memoization and should be closer to lists in dificulty-level than to iterators. The reason it seems to be at the level of iterators is related to language definition, documentation, ontology eg the 'fact' that foo looks like a function when conceptually/ontologically/implementationally it is not. This is a language-goofup not student ignorance One more minor nit with Steven's intermediate-list: Command line parsing with optparse/argparse. Well if you use an obese library you get what you ask. Whats wrong with getopt? Seems to me simple enough for a beginner to write simple scripts As I said this is a little nit. However the pedagogic principle is important. argparse may be recommended whereas getopt may be deprecated [dunno if it is] Nevertheless pedagogic expedience is not the same as real world best practice. <Admission> In a recent course I taught, I used a[0] and a[1:] to split arrays and write recursive functions a la Haskell in Python. Is it efficient? no Is it idiomatic python? NO! Is it good to do that? That depends on one's priority. In mine, learning recursion is more important than learning idiomatic python </Admission> -- https://mail.python.org/mailman/listinfo/python-list
