What is considered an "advanced" topic in Python?

[Rustom Mody]

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>