
Advice on learning Python efficiently - dwaynecrooks
http://www.simplydjango.com/learn-python-efficiently/
======
hardwaresofton
Pretty good advice, along with some good pointers about what NOT to do when
learning a languages (ex. reading some instructional book cover-to-cover,
forgetting most of the stuff along the way).

I often suggest the read-a-chapter-write-a-program-based-on-it route, just to
get the practice that is really important, and to solidify some intuition as
to what the machine (whether interpreter or bare metal) is doing, and to make
writing future programs easier.

Side note: While I definitely applaud the idea of trying to create a language
that is geared towards beginners and good for learning on, I don't know if I
can get behind recommending such a language that is still under development
being suggested to beginners.

Then again, I'd consider recommending lisps to beginners (if not python), so
maybe I'm not the most credible source

~~~
trymas
> Side note: While I definitely applaud the idea of trying to create a
> language that is geared towards beginners and good for learning on, I don't
> know if I can get behind recommending such a language that is still under
> development being suggested to beginners.

I second this. Especially when python itself is very beginner friendly.

IMHO the best advice on learning a skill is just do some projects with it. I
am not exactly sure, which should come first, the 1. or the 2. point made in
the article.

Though I would dare to say the 2. point is more important.

By doing python projects first you familiarize with it and then if you are
still on - you should read zen of python, pep8, etc..

~~~
praveer13
>By doing python projects first you familiarize with it and then if you are
still on - you should read zen of python, pep8, etc..

Would you mind recommending some projects for a python beginner?

~~~
drcongo
I find scratching one's own itches is always the best way to learn a new
language. Solve a problem that you have.

~~~
HelloNurse
Problems are not all the same: choose one that stresses and challenges the
language, to gain confidence in its strengths and practical expertise.

For example, I once tried to learn Haskell and I started from little exercises
([https://wiki.haskell.org/H-99:_Ninety-
Nine_Haskell_Problems)...](https://wiki.haskell.org/H-99:_Ninety-
Nine_Haskell_Problems\);) I got familiar with syntax and basic concepts, but I
was dissatisfied both with the easy, abstract questions and with the
simplistic, inefficient answers using basic standard library features that are
more or less the same in any language. What was "real" Haskell code like? I
expected dealing with serious libraries, memory management etc. would be
uglier, more difficult and more cumbersome than exceptionally terse toy
examples.

So I attempted something not merely useful and small, but with a well defined
practical objective, depending on external standards, requiring production
quality libraries and with performance challenges: converting the metadata
dump from MAME (a nearly 200MB XML file) into an easy to use SQLite database.

The task was a good test of programming language productivity because, having
already used ElementTree and APSW I was sure I could write it in Python quite
easily. (And I did; a complete Python implementation, able to roundtrip data
back to the XML format for testing purposes, took me less time than an aborted
Haskell attempt that could parse a dumb document tree using a ridiculous
amount of memory.)

This project allowed me to discover many things about Haskell that are not
found in enthusiast-written tutorials: the mess of incompatible and
undocumented libraries, the impracticality of basic language design decisions
(text handling, lack of namespaces leading to name conflicts, etc.) and my
profound disgust for the commonplace syntactic tricks.

Of course, a similar challenge for Python is likely to have a better outcome:
learning the difference between good and really good libraries, finding a use
for many language features, remembering useful idioms nd design patterns, etc.

------
eric_bullington
For many years, I worked on the periphery of the programming world, but with a
very superficial level of programming knowledge. I was a "webmaster" back in
the mid 90s, working with simple PHP, JavaScript and VB scripts. I then went
to grad school for public health and afterwards worked in several biostat-
oriented research analyst roles focusing on Stata and SPSS programs.

All these jobs definitely involved a very basic understanding of programming,
but I had no understanding of many important fundamental programming concepts,
and had created very few programs bigger than a 1-page script.

It was only when I started to learn Python, and then C (to write Python
extensions), that everything really clicked. Something about Python made it so
much easier than PHP or JavaScript for me. I think Python's relative lack of
glyphs, brackets, and other "syntactic noise" (my opinion only) made it much
easier for me personally to grasp big picture ideas. Python also prepared me
for learning C to a pretty good level (with much help from the K&R book).

These two, in turn, gave me a good foundation for branching out into other
languages, eventually including functional programming languages.

But Python was with no doubt the turning point for me, and even though I do
little Python work these days (ironically, I'm back to JS but at a much higher
level than in the 90s), I'll always be grateful for Python.

If you've struggled with programming and haven't given Python a shot, give it
a try! If that doesn't work, maybe try Pyret like this post advises (once it's
stable), or maybe some lisp such as Clojure. I also know some mathematicians
who struggled initially with imperative programming but then thrived with
Haskell. Point is, we think in different ways, so keep trying different
approaches until something sticks.

~~~
dwaynecrooks
> Point is, we think in different ways, so keep trying different approaches
> until something sticks.

So true, great advice. You have to experiment and find out what works for
yourself.

------
Groxx
Hmmm.... I'll disagree on the "don't read a book" suggestion.

I've hung around on a number of support chat rooms for languages / libraries
for a few years, and _tons_ of the problems we hear about are things that
nearly any book would've made plain. As further evidence, 99% of Stack
Overflow is filled with this stuff.

In my experience, skipping the dry stuff to get started faster tends to lead
to poor mastery of a system. You can _absolutely_ waste time on the dry stuff
- don't read a 1000 page book when 100 will do (or ever; huge books are
usually awful) - but the details very often matter in the long run when you
start doing anything not in a cookbook / tutorial. Yes, you can always go back
and read it later, but _very few do so_. Investing a day or two in a detailed
book up-front isn't that much time.

------
ManlyBread
>It's called Pyret.

How about just learning Python instead of learning a toy language and then
having to learn Python anyway?

~~~
jerf
Python has gotten hard to learn. It's not too bad if learning it just to
learn, or learning it in a classroom setting with a careful plan, but I've
witnessed people trying to learn it professionally in the context of getting
testing running, and it's hard to learn when trying to use a mature Python
codebase that uses Python thoroughly. There's these decorators, and iterators
vs. functions, and things using introspection to do invisible things, and on
and on it goes.

Python used to be easy to learn. It isn't anymore. It may be a better language
for all the feature additions, but it isn't easy to learn anymore and I no
longer recommend it for that purpose. (I don't have a recommendation at the
moment.)

~~~
VT_Drew
>Python used to be easy to learn. It isn't anymore.

Compared to C++, C# and Java, Python is still MUCH easier to learn. Python and
Ruby are the easier languages to learn. I have to agree with the other
commenter, why learn a toy language only to later have to learn a real one?
That is a waste of time.

~~~
mangodrunk
Well, shouldn't it be about learning how to program. Not necessarily learning
Python or Ruby? You will learn how to program with languages like Python,
Ruby, Java, etc. but you will have to work with constructs/abstractions that
might make sense in a professional setting but not so much in an academic
setting.

------
poletopole
Not sure if this will help anyone out there, but learn how to take notes
efficiently first. Learning a markup language helps a lot. Be very selective
when choosing a book; don't hesitate to throw away a crappy book. Avoid books
geared towards getting you "up and running" despite their reviews, they're
never worth it. The more sources the better. The only subjects I don't spend
time on are non-core API methods; just take note that there is an API and
where it is, but referring to the official documentation is better because
there's never much you can add of value. Ultimately plan on spending 6-9
months of weekends or 2-3 solid months to learn the bulk of a new language if
you're taking notes. If it's your first programming language picking a simple
project to do is helpful because otherwise you won't know the "why".

------
metaphorm
Pyret looks nice, but I think it's misleading to say it's "Python inspired".
At first glance it looks more like its cribbing ideas and syntax from Ruby and
OCaml.

~~~
jpolitz
It's true, Pyret gets ideas from a handful of places, not just Python.

From a student or instructor's point of view, it is serving a lot of the same
ends as some of Python's choices:

Toplevel code runs as a script without ceremony, the default behavior doesn't
statically check types but is conservative about coercing types and
overloading operators (e.g. "a" \+ 5 is an error), integers promote to bignums
by default (though Pyret supports exact rational bignums as well).

Pyret supports docstrings explicitly, and examples/check blocks have
similarities to Python's doctest.

Fields of ADT instances can be accessed simply with "." (in contrast to OCaml
or other functional languages), and methods close over self on dot-access as
they do in Python.

Some of these things are also true of Ruby, so that's a fair comparison as
well. And things like "data", and the gradual type-checking facilities, are
clearly coming from other sources (though Python is moving in a gradually-
typed direction as well).

I know we were thinking about Python in particular when we made a lot these
decisions, so I think it's a fair characterization, though Python is one of
several inspirations.

------
Walkman
Pyret's syntax looks far more complicated to learn than Python's for a
beginner.

~~~
jpolitz
I'm curious which parts look (more) complicated to you.

For some perspective, when teaching Pyret to total beginners, we start with
arithmetic and calls to library functions, then build up to function
definitions and examples. At that point, there's just a handful of syntactic
constructs to consider, and they are nearly identical to Python.

Things like "data" and "cases" don't come till later, and do come with more
overhead, but also are introduced to students who already have some "finger-
feel" with the language. Python has its own overhead with "class" for defining
structured data at a similar point, including things like "self" and
"__init__".

~~~
tim333
I noted the in first example in the linked into - Python:

    
    
        def square(n):
          return n * n
    

Pyret:

    
    
        fun square(n :: Number) -> Number:
          n * n
        end
    

there's extra stuff. It also kind of loses the elegance of Python reading
close to normal language - if you don't know programing but can do math you'd
figure the first was define a function that gives a square but be confused
what (n :: Number) -> Number: was about.

~~~
jpolitz
The type annotations are optional, so

    
    
        fun square(n):
          n * n
        end
    

is a closer direct comparison to the Python program, for contexts that don't
use annotations.

------
jMyles
Teaching and learning are spaces where many flowers can bloom, so I can
appreciate the angle of this article (and thus Pyret).

To zoom in for a second: in my experience teaching, the simplicity of the
outdent as a mechanism for ending a control structure is a light-bulb moment
for many people. I don't think that adding "end" is helpful for this segment
of the population.

And so it is with `where`, which seems to shoehorn a BDD / Rspec'ish approach
which, while typical of some of the best Ruby out there, is not typical of a
Python library.

Again, this approach may be great for some people, but I'll bet that it won't
be great for others.

------
sytelus
This is great post and the observation is quite applicable in pretty much
every subject that you want to learn and master, not just Python. In fact,
"learning to learn" is perhaps the most important skill we develop as humans
and a small improvement in this area translates to order of magnitude
improvement in actual learning. In PhD programs they say that getting PhD is
not actually about mastering specific subject but rather developing an ability
to comb through vast amount of knowledge, assimilate it and synthesize new
knowledge. The first two steps is where much of the effort lies which is
"learning to learn". The first mistake that most people make in first step is
trying to understand everything cover-to-cover of each paper before moving on
to next. An experienced person would first try to get big picture (just look
at the abstract and results :)) and move on to next one. So you do breadth-
first-search followed by some selective depth-first-search and continue back
and forth until you build "surface" that represents the usable approximation
of state of the vast amount of knowledge. This is many order of magnitude
efficient than try to build most of the "surface" from the get go.

------
faitswulff
> Since Python isn't your first language

I didn't realize this wasn't for beginners until I got to this section and
read that his first application was a whitespace interpreter.

Personally, coming from Ruby, I learned Python via
[https://learnxinyminutes.com/docs/python/](https://learnxinyminutes.com/docs/python/)
after stumbling a bit on the Python 3 import syntax, which I came to love.

------
dimino
Be pythonic, be pythonic, be pythonic!

My biggest complaint about python is how easy it is to learn (heh). It takes
so little effort to write a script, so it feels deceptively easy to write
great python. After all, as long as it works, who cares right?

I care. Your colleagues care. Your users care. Python is an object oriented
language, use it as such.

~~~
xamuel
>My biggest complaint about python is how easy it is to learn

This X 1000. Some Python candidates declare themselves professionals when
their code is unsuitable for production.

If you're gonna spend many thousands of hours using a language, don't use
initial learn-time as the one thing to optimize for!

~~~
dwaynecrooks
> If you're gonna spend many thousands of hours using a language, don't use
> initial learn-time as the one thing to optimize for!

That reminds me of this wonderful talk by Rich Hickey called Simple Made Easy,
[https://www.infoq.com/presentations/Simple-Made-
Easy](https://www.infoq.com/presentations/Simple-Made-Easy).

------
pbreit
Intro to python and get a web service built in an afternoon or so:
[http://www.web2py.com/books/default/chapter/29/02/the-
python...](http://www.web2py.com/books/default/chapter/29/02/the-python-
language)

------
Gusbenz
I've definitely purchased some programming books with a rabid ardor only to
set it down 40 or so pages later only to open another book purchased with the
same rabidity.

------
happy-go-lucky
Looks like another clickbait. Learning a language and creating a new one are
not the same.

~~~
peatmoss
Where did you get that from? I feel like we read different articles. Are you
referring to the introduction where he suggests that people entirely new to
programming should check out Pyret?

~~~
happy-go-lucky
According to the article, learning Pyret is an efficient way to learn Python.
It's a misleading title.

~~~
dwaynecrooks
Huh? Where in the article did I say or imply that learning Pyret is an
efficient way to learn Python? I said if you're a complete beginner then you
can consider Pyret. As for people who already know some programming I didn't
suggest Pyret to them at all.

------
agumonkey
I may suggest Julien Danjou python's book. Only skimmed through it, but it
felt funnier and more in depth (covers AST for instance).

------
tomquin
As a 'code tourist' i find focusing on what i need for a specific project the
best way to learn new languages.

------
happy-go-lucky
Is there an easier language than Python? This is not to belittle this effort.

------
geezerjay
Can someone fix the misleading title?

Stating "Learn python efficiently" is one thing, but stating "My advice on
learning Python efficiently" is another entirely different thing. One is a
statement of fact, another is just yet another opinion.

Accepting clickbait articles degrades the quality of a news aggregator.

~~~
dwaynecrooks
That's true, sorry about that.

Thanks to whoever fixed it.

