90% of Python in 90 Minutes (2013) | Hacker News Reader

90% of Python in 90 Minutes (2013)

slideshare.net

384 pointsTomte56 comments

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

thanks, its a nice quick ref. bought.

As one content creator to another: thank you for the material, especially at a reasonable price of $10. Purchased.

I appreciate that. Thanks!

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

Why not purchase it and give it away?

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

As a self published author, the best way to support me is to review on Amazon or share on social media :)

Thanks for the cool reference! :-)

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.

> 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.

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.

> That's nowhere near 90% of Python. [...] the interpreter has so much going on you can't learn everything in years. [...] the ecosystem, which is so large nobody can know about every package.

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 send people here for a summary: http://web2py.com/books/default/chapter/29/02/the-python-lan...

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

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

It is also worth noting that in most languages -2 / 3 yields 0 and not -1, i.e. integer devision rounds towards zero, not towards negative infinity.

Yes, in fact that's the point I'm trying to focus on but never made explicit. Thanks.

Integer division rounding toward negative infinity makes it so that for integers a, b, with b > 0, then if a%b is defined as a - b * (a/b), you will always have 0 <= a%b < b.

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.

Eric Lippert, a former C# compiler developer, has a good blog post [1] discussing the reasoning and the difference between modulus and remainder.

[1] https://blogs.msdn.microsoft.com/ericlippert/2011/12/05/what...

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).

> 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?

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.

Also, if you need simple (though not necessarily immediately obvious) ceil division, you can do this:

    -(-a // b)

As in:

    >>> 1 // 2
    0
    >>> -(-1 // 2)
    1

This works because the floor division is truly a floor (and not a truncate), so floor division of a negative number is "rounded" towards negative infinity, and not towards zero.

With stuff like this, any ports of existing Python 2 codebases are wont to lead to tons of subtle bugs. No wonder Python 3 adoption is as low as it is.

The // division is like the mathematical division where the remainder is positive (a = qd + r and 0 ≤ r < |d|). If -2 // 3 would give you 0, it means the remainder is -2 which is a no-no. If -2 // 3 gives you -1, the remainder is 1 which is fine.

It was introduced as floor division:

https://www.python.org/dev/peps/pep-0238/

And is currently documented as such:

https://docs.python.org/3/tutorial/introduction.html#numbers

https://docs.python.org/3/glossary.html#term-floor-division

https://docs.python.org/3/library/operator.html#operator.flo...

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.

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

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

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

Absolutely. Not using mutable variables as default arguments = 91%

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

Blinking LED now in Node.js.

Similar to the 90-90 rule: https://en.wikipedia.org/wiki/Ninety-ninety_rule

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

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/

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.

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.

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.

I disagree. As a new coder when looking at a new language you don't know what's the same as what you're used to and what's different. Some things may be almost exactly the same but be slightly different. For example Python's division converts ints to floats in Python 3, for example. If you just leave out everything that's the same, the reader won't know what it's the same as.

Also, the same compared to what? C? Everyone's first language is not the same.

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.

I'd add unicode to this. Now the only string type is unicode in Python 3.

I think [1] and [2] are good places, not sure if there's an absolutely easy-to-navigate summary from 2-3.

[1]: https://docs.python.org/3/howto/pyporting.html [2]: http://python-future.org/compatible_idioms.html

Bytes/Unicode strings is the biggie for anyone doing I/O.

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.

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.

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

About slide 51: "No Multi-line comments"

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

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.

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.

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.

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.

> l.extend(12)

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

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

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

Ah, true, my bad.

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.

https://www.slideshare.net/MattHarrison4/learn-90/61?src=cli...

Super useful, would be nice as anki deck.

Reply on news.ycombinator.com