
Python progression path - From apprentice to guru - limist
http://stackoverflow.com/questions/2573135/python-progression-path-from-apprentice-to-guru
======
njharman
The top answer seems to be for the question "How do I learn to program Python
using only the functional style". Which is __FAR __from being a Python Guru. A
Guru knows how to use Python for many styles and to mix them for optimal
effect.

#11 "balance" is laughable based on the preceding ten.

Some things missing include:

    
    
      * properties (glaringly so)
      * slots
      * meta classes
      * dynamic code generation / data as code
      * emulating various types and the rest of __methods__
      * know thy standard lib
      * distribution setup tools, et al
      * documentation epydoc, sphinx, docutils, et al
      * profiling and performance
    

Also from the top answer.

"... Python class. Claim it could be "better" implemented as a dictionary plus
some functions"

Um, that is almost all a Python Class is.

~~~
evgen
While the OP's list has a more functional outlook than most similar lists, for
most Python programmers the difference between being average and being good in
Python is in knowing when to drop into functional paradigms. Your list
contains a couple of key points the OP missed (grokking properties and the
standard lib) but takes a similar divergence when you get into things like
slots, meta classes, and dynamic code generation that are the primary source
of code smell from wannabe Python gurus. 99.99999% of the time you will not
actually need them and are just throwing it in to demonstrate your 'leet
python skillz'.

~~~
hartror
Sure, but as a guru you know how to and when to use them.

------
steveklabnik
I'm really into the whole "code as craft" idea, though a lot of my thoughts on
the subject aren't fully baked.

It seems to me that we're at a place with software where we were with, say,
civil engineering in roughly 2000 BC or something. This date is horribly
wrong, but what I mean is that we're building basic structures, and we're okay
at it, but when we try to do anything larger, we're failing.

At some point, we'll be able to make larger buildings, bridges, and roads...
but we're not there yet. It seems like the best path forward is to follow is
to do exactly what early engineers did: an apprenticeship model. Yes, software
is based in math, but so are bridges. We've got a better grip on the math now,
and it does help us build modern bridges, but at first, we had to schlep
along.

I'm starting to ramble slightly, so I'll cut this off. And as I said, this is
only a half-baked thought... but I think this 'apprentice -> journeyman ->
master' path is an intriguing way to move forward with software.

~~~
gaius
That's not quite true: we _do_ know how to make large, complex, highly
reliable programs.

It's just that in most cases, no-one cares enough to pay what it costs. You
either have to be extremely high profile (e.g. the Space Shuttle) or doing
huge volume (think of a CPU as simply a Verilog program) to make it
worthwhile. Would you pay 10x as much for a word processor or web browser that
never, ever crashed? Would you pay 100x?

~~~
steveklabnik
The problem with the space shuttle example is that it has incredibly limited
scope. Yes, we could build a large program to exacting specifications, but
once they change, all bets are off. The space shuttle software doesn't need to
adapt over time.

And you're right, it is incredibly expensive... but even in my example, that
just moves us forward to the Roman Empire, or something. People know how to
build an aquaduct, but only the most excessive society on the face of the
planet can afford it.

~~~
gaius
But if we're sticking with the civil engineering analogy, a road is not built
in 1-week sprints with the route potentially changing as requests come in that
it link more or different towns. So you have to compare like with like.

~~~
steveklabnik
There's a reason that I said my thoughts are half-baked. ;)

Good point.

------
Estragon
This is like saying you can be fluent in Japanese by learning the grammar and
saying nothing about the vocabulary. Fluency with the libraries python offers
is far more important than whether you express yourself imperatively or
functionally.

That said, I'm off to the library to borrow a copy of _Real World Haskell_.

------
plesn
The first answer is interesting but I don't understand step 10. Imperative is
a model with state and deterministic sequence and Haskell constructs like
state and IO monads form imperative DSLs (with some typing burden/advantages).
I don't see why the strategy pattern is particularly interesting here (but I
see why imperative structures like mutable arrays and associative arrays are
interesting). I don't see either why I would especially forget all those
design patterns outside of imperative code : for instance the presentation of
Connal Elliot "Tangible Functionnal Programming" is a great exemple of the use
a kind of MVC pattern precisely to avoid using imperative constructs.

For me at least, the balance lies more in the use of state (easy in python) or
the cost of abstraction (no inling and TCO).

~~~
silentbicycle
Dude, it's a joke. Going to one extreme (trying to write Haskell-style code in
Python), then the other (OOP code dripping with Design Patterns), then finding
a balance.

(I know what he's talking about with Haskell-in-Python, though. I did that.
Briefly.)

------
Kilimanjaro
Learn to simplify and beautify.

We learn new tricks just to make our code simpler and prettier. As a side
effect, we code faster and with less bugs.

