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.
If you have any questions, fire away, and I'll do my best to answer them.
I'm pretty sure that this "90% of Python" is in the context of the stuff an already-experienced developer needs to absorb to honestly put "Python" under "Languages" in a resume...
... Not the amount of knowledge you need to say "I know everything there is to know about Python, it's implementation details, and its entire associated ecosystem of third-party applications."
> but that's not True at all
Can't tell if intentional, or habit :P
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.
(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.
Then in a few more minutes can learn a framwework and be programming: http://web2py.com/books/default/chapter/29/01/introduction
> (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
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).
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?
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.
And is currently documented as such:
-(-a // b)
>>> 1 // 2
>>> -(-1 // 2)
Integer division rounding toward zero makes that not so. a%b for negative a, positive b, will be <= 0.
On the other hand, rounding toward negative infinity means that (-a)/b != -(a/b), when b does not divide a. Rounding toward zero makes (-a)/b = -(a/b).
I think most mathematicians would rather have 0 <= a%b < b than (-a)/b = -(a/b) if they can't have both.
If you find yourself downvoted and wonder why - please consider two things that don't go down well on Hacker News:
1. Arbitrary capitalization for emphasis and multiple exclamation marks makes you sound a little breathless and over-excited.
2. Your post was pretty much content-free.
It is kind of the same approach to the beginning of a new language.
Here is the direct link for the python3 source:
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.
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.
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.
Also, the same compared to what? C? Everyone's first language is not the same.
Also relative/absolute imports can cause some confusing bugs.
I think  and  are good places, not sure if there's an absolutely easy-to-navigate summary from 2-3.
You can use triple-quote strings as multi-line comments: https://twitter.com/gvanrossum/status/112670605505077248
...For a list "l": that is wrong, "extend" expects an iterable, not an int.
Double confusing since the comment text, especially with the font, hints more at the "add twelve" case:
> "Add l2 items to list"
If it was worded for example "Add items of l2 to l", I think I would not have misinterpreted it.