
90% of Python in 90 Minutes (2013) - Tomte
http://www.slideshare.net/MattHarrison4/learn-90
======
mharrison
Just noticed this on my commute home (author of slides).

This is an old and condensed version of corporate training that I run.
Typically the training runs for some 4 days. If you want a more modern version
of this material (that you can submit your PR's to), check out my Python 3.6
reference[0].

If you have any questions, fire away, and I'll do my best to answer them.

[0]- [https://github.com/mattharrison/Tiny-
Python-3.6-Notebook](https://github.com/mattharrison/Tiny-Python-3.6-Notebook)

~~~
voltagex_
Is there any other way to support you? I don't really need any more physical
books.

~~~
icebraining
Why not purchase it and give it away?

~~~
raybb
Specifically, you could give it away to a local library :)

------
Walkman
That's nowhere near 90% of Python. It's strange because everyone thinks Python
is an easy language to learn, but that's not True at all. It's easy to pick up
and be productive with it in a very short time, yes, but the interpreter has
so much going on you can't learn everything in years. If you happen to learn
everything about protocols, the interpreter gotchas, there is the standard
library which is also huge, and if you got everything in it, there is the
ecosystem, which is so large nobody can know about every package. And I did
not talked about the whole new world of Python3, asyncio and the whole old
world of Twisted.

~~~
jacquesm
> If you happen to learn everything about protocols, the interpreter gotchas,
> there is the standard library which is also huge, and if you got everything
> in it, there is the ecosystem, which is so large nobody can know about every
> package.

I don't think the library and packages are part of the language though. Just
like there is a 'C' without a standard library there is Python 'the language'.

As for the 90%, 90% of the code you write is boring and simple. The one thing
I really missed in the slides was list comprehensions, presumably they are in
the '10%', but I use them all the time.

~~~
mharrison
Yeah, these slides were for a long conference talk that introduced the basic
syntax of Python to developers who weren't familiar with Python.

(List) comprehensions are super cool, as are generators, decorators, etc, but
there just wasn't enough time to cover that. Plus, as you say most code is
boring, and you can get by with the material in this deck.

------
pbreit
I send people here for a summary:
[http://web2py.com/books/default/chapter/29/02/the-python-
lan...](http://web2py.com/books/default/chapter/29/02/the-python-language)

Then in a few more minutes can learn a framwework and be programming:
[http://web2py.com/books/default/chapter/29/01/introduction](http://web2py.com/books/default/chapter/29/01/introduction)

------
wyldfire
From slide 32:

> (In Python 3 // is integer division)

I find it clearer to describe this behavior as "floor" division. You might
think "integer division" would have the same results as python 3's `int(a /
b)` when `a` and `b` are ints, but, no, this is not the case. I never could
quite understand why all the hub-bub about "integer division" and why it
should change from python 2 to python 3 because the behavior seemed natural
and similar to the native integer division on most processors. Indeed its
behavior is astonishingly different with negative numbers.

    
    
        $ python2 -c 'print 2/3, -2/3, int(-2./3.)'
        0 -1 0
        $ python3 -c 'print(2//3, -2//3, int(-2.//3.))'
        0 -1 -1
        $ python3 -c 'print(2/3, -2/3, int(-2./3.))'
        0.6666666666666666 -0.6666666666666666 0

~~~
paulddraper
The term "integer division" comes from the fact that Python 2 a/b is the same
as Python 3 a//b if a and b are integers.

It's not the same as int(a/b), because like most languages int() rounds toward
zero, and unlike most languages Python division rounds down.

100% agreed that "floor division" is a better description (e.g. it covers
floats too).

~~~
eric_h
> like most languages int() rounds toward zero, and unlike most languages
> Python division rounds down

As someone who only occasionally needs to manipulate python, and someone who
rarely needs to do integer arithmetic on negative numbers (beyond
addition/subtraction) this caused me to do a double-take.

I'd always just assumed that languages that treat floats and integers
separately would always round integer division towards zero, but TIL python
rounds to the left on the number line.

It's really true! Turns out it's true in ruby, too:

-5 / 4 == -2

How 'bout that. Anyone know what other languages treat integer division in
this way?

~~~
jacobolus
In both cases, b * (a // b) + a % b = a, which is often a behavior that you
want.

In some other languages, the % operator (IMO wrongly) takes the sign of a,
making it more like a “remainder” operator than a “modulo” operator, whereas
in Python % (IMO correctly) takes the sign of b.

I also agree that this should be thought of as “floor division” rather than
“integer division” though.

------
Dowwie
Learning Python is easy but learning how to use Python well isn't. However,
learning to use Python well pays great dividends and so the experience is
worthwhile.

~~~
mharrison
Hence, when I'm doing a corporate training, this material takes about three
days to cover.

------
jerryszczerry
I guess if learning 90% of something takes 90 minutes, the remaining 10% will
take 10 years.

~~~
scalesolved
And that is where problems start with keen and eager junior developers who
think by knowing the 90% they really know the 100%.

~~~
sotojuan
Unfortunately here in HN we constantly upvote those junior developer's Medium
posts.

~~~
jacquesm
Blinking LED now in Node.js.

------
Fake4d
I really love the learnxinyminutes project. If anyone doesnt know it here is
the Link:

[https://learnxinyminutes.com/](https://learnxinyminutes.com/)

It is kind of the same approach to the beginning of a new language.

Here is the direct link for the python3 source:
[https://learnxinyminutes.com/docs/python3/](https://learnxinyminutes.com/docs/python3/)

------
lucasmullens
This seems like a less-polished version of 'Learn X in Y Minutes'.

Dropping phrases like "REPL" and "PEP" and only defining what they stand for
doesn't really explain what they are. And the explanation of dunder methods at
first seemed to suggest there are only 2.

And calling this 90% of Python is really misleading. It's not even 90% of the
syntax, let alone the whole language.

------
danbruc
You could easily reduce that ten fold, most of the slides contain little
information. Every developer already knows that you can add integers, combine
booleans with and, and have alternatives with if and else. Or how lists and
maps work. No need to repeat this in such detail, just list the type names,
keywords and operators.

Instead focus on what is special about Python like indentation and colons,
slicing, __iter__, arbitrary precision integers, ... This are the important
things, otherwise you can not really say you know much about Python because it
is generic stuff that applies to most languages under the sun.

~~~
jacquesm
You can just skip the slides you already know.

Everybody has a different level of proficiency as a developer and a guide like
this is aimed at a beginner, not at a seasoned developer. Since you don't know
their background it doesn't hurt to repeat already familiar stuff because it
is easy to move past that quickly if you already know it, but it would be a
lot harder to make sense of the package if you so much as miss one or two
simple steps or elements.

For me one of the take-aways was the negative stride in a slice, I had not
seen that yet and a couple of clever tricks such as 'dir' and 'help'. I've
been doing nothing but python lately, and going through the whole deck to stop
at the things I didn't know yet took only a couple of minutes.

------
rubatuga
Although this ignores most of the differences between Python 2 vs 3, note that
there will be differences in iterables, classes, and print functions. Feel
free to comment if you aware of any more.

~~~
tempay
Generally projects that suffer from the str/bytes/unicode mess is the hardest
to port in my experience as 2to3 can't really help.

Also relative/absolute imports can cause some confusing bugs.

~~~
xapata
That's because the programmer needs to make the choice of whether the data is
text or just bytes. I suppose you could write a tool to infer that choice, but
it wouldn't be perfectly accurate.

~~~
tyingq
And see if that choice lines up with the v3 compatible version of any
libraries they are using. Ones that touch the data anyway.

------
mozumder
About slide 51: "No Multi-line comments"

You can use triple-quote strings as multi-line comments:
[https://twitter.com/gvanrossum/status/112670605505077248](https://twitter.com/gvanrossum/status/112670605505077248)

------
Xcelerate
This is a nice little presentation! Although I wish there was a "context
switching" guide that highlights the main differences between all of the
languages. After working in Julia or Python for 8 hours, I switch to
JavaScript and suddenly forget how strings work. I wish there was a giant
table with all of the main differences between the major languages listed so I
can glance at it quickly and be on my way.

~~~
jacquesm
That's my main reason for thinking really long and hard about what eco-systems
to invest in. I've settled on Python and Erlang for now and I really hope that
that bet will pay off. Everything else except for Java seems transient to me.

------
farhannyc
Why are these books always focused on a fast learning principle? I really
don't think anything useful can be made from 90 minutes of quick reading. It's
a great refresher for people that didn't work with the language for a while.
Now I remember python's annoying indents.

~~~
hamandcheese
Its potentially valuable for anyone who needs to do some quick work in Python.
There are quite a lot of little Python scripts I work with, even though I
mostly do Ruby. I don't need (nor do I want to) become a Pythonista just to
make some edits now and again.

------
asmosoinio
> l.extend(12)

...For a list "l": that is wrong, "extend" expects an iterable, not an int.

~~~
jwilk
It's l2 (another list), not 12.

~~~
jachee
A clear case where the "Readability counts." principle from "The Zen of
Python" applies.

------
jacquesm
Super useful, would be nice as anki deck.

