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.
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.
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.
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.
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.
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.
> 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.
Python doesn't have 'mutable variables'. I think you mean 'not binding mutable values as default arguments', but that's totally fine. What's wrong is not understanding when default arguments are bound. There's nothing inherently wrong with this:
class Wrapper:
def __init__(self, wrapped):
self.wrapped = wrapped
def counter():
def inner(w=Wrapper()):
w.wrapped += 1
return w
return inner
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.
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.
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.
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."
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.
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.
60 comments
[ 1.5 ms ] story [ 173 ms ] threadI 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
Also relative/absolute imports can cause some confusing bugs.
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.
> (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.
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.
[1] https://blogs.msdn.microsoft.com/ericlippert/2011/12/05/what...
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.
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...
Then in a few more minutes can learn a framwework and be programming: http://web2py.com/books/default/chapter/29/01/introduction
Wow !!! so funny , but TRUE
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.
So TRUE !!!!
...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.
https://www.slideshare.net/MattHarrison4/learn-90/61?src=cli...
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.
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.
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
You can use triple-quote strings as multi-line comments: https://twitter.com/gvanrossum/status/112670605505077248
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://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/