"""-delimited text is not actually a comment. Its a multiline string literal
x = """aaa
bbb"""
And you can also use single quotes if you want.
x = '''aaa'''
The reason this might have been confused with a comment is because triple-quoted strings are often used for documentation strings, a Python feature that gives special meaning to string literals that occur as the first statement in a function or class. Those strings get associated to the function as its documentation and can even be inspected at runtime:
def foo():
"my documentation string"
return 17
print help(foo)
This is exactly what I wanted a few years ago while working on a GAE project. I had never touched Python but I knew programming and just wanted to know what the language had and how in basic terms to use it.
I remember picking up a large book from a store shelf titled something like "Python for Programmers". Thinking, "Oh, this is for people who already know how to program and just want to learn Python". I open the book randomly and start reading it's explanation on what functions are in programming and why they're useful. I sighed and placed the book back on the shelf.
An error: *args arrive as a tuple, not a list, so the first line that all_the_args(1, 2, a=3, b=4) prints is not:
[1, 2]
but is instead
(1, 2)
The second line of that output also happens to be wrong, because printing a dictionary uses repr() on its keys and values and str.__repr__ normally uses single quotes, so instead of
{"a": 3, "b": 4}
It will instead print
{'a': 3, 'b': 4}
For that matter, I would prefer it if this guide used single quotes primarily; that is the preferred standard in Python.
Nice and concise. It would be complemented nicely by a list of Python "gotchas".
E.g., off the top of my head, mutable default arguments, or trying to catch multiple exceptions with "except Exception1, Exception2:". That's the kind of thing people new to the language can spend a lot of time debugging when they first run into it.
Edit: and any introduction to tuples should probably show how to write empty and one-element tuples, since that can be non-intuitive. Writing (1) instead of (1,) is also a fairly common gotcha.
This looks very similar to the notes I was taking on my own when going through "learning python the hardway". Yours are much better and easier to read though, and make more sense in terms of going from very easy to more complicated in staggered steps.
Great stuff!
As a sidenote, how does everyone take note (if you even do) when learning something new like a language or some kind of skill?
What taking notes does for me -- and I assume most other people -- is that it forces me to internalize what I just learned in a way that makes sense to my brain and fits within previous constructs I've already developed through n years of living.
I make guesses about what the result of something will be, check the guesses to see if they work and then write down why I think they worked or didn't work.
What this needs is Rap Genius style annotations, so people can make comments and additions. I recently (re:yesterday) decided to pick up and try out python for a small project and this is a great quick and dirty start.
While I see value in a cheat sheet that helps you remember a language's features, using the words 'Learn X in minutes' is a bit stretching it. It takes a good few weeks to get comfortable building something in a new language.
Having just recently learned Python the "hard" way, I really wish I would've seen this beforehand. Even having done some hands-on work and a lot of Googling, I picked up a few new things from this I hadn't seen before. Thanks!
Same here, I just went through the same course. (Learn Python the hard way).
Coming from a php background I had (and am having) problems wrapping my head around the packaging section. I started to lose interest because of it. It's as if I hit a wall.
Can any Python hackers offer some good resources for learning more about packaging?
If you email me with the problems you had I'll see what's wrong with the exercise and figure it out. There was a particularly stupid ordering problem with it where I had people install requirements after they needed them, so go double check it again and see if it got better.
Also, email me help@learncodethehardway.org with what you ran into. If you're in San Francisco I'll even meet you in person to figure out what you're doing live (works way faster).
I haven't been able to find a decent tutorial on creating packages. That particular section in "Learn Python the Hard Way" was hard for ME to follow. I was able to create a package but only after finding a link on stackoverflow question that then redirected me to a github page containing a sample package from an individual who also had problems. He states that his package worked but he wasn't sure if he created the package correctly.
I've tried reading the python documentation but I'm too dumb to understand some of the language. (No CS background, just a regular dude and a computer here.)
The bit about exceptions, using a comma instead of as, should just be left out. I don't imagine anyone starting out today is using Python < 2.6, and having both in the document is confusing.
int, boolean, float etc. are not _primitive_ data types in python. If you say that, you really have no idea, what you are talking about. They are objects like everything else. You can inherit from them and do all the good OO stuff.
Sorry for the nitpicking, but calling them primitive types, is just plain wrong.
Sorry for that. I know they are objects but if you consider everything an object then really you have no primitives except object itself. Certainly this has a place in programming philosophy but not really a helpful point in a language-primer/cheat sheet.
I agree that "everything is an object" doesn't mean much but "primitive types" has a strong meaning when it comes to OO programming so a different term might be more appropriate.
I'm usually a php guy, and recently I had to use some vendor's python api to do some data integration and this might have come in handy. I picked up python, or atleast the basic syntax in roughly 1 day, and was done with my implementation within the next day.
This might be even more useful as an ipython notebook so that people can modify and execute any of the examples.
The easiest way to host a notebook that users can try from their browser seems to be Wakari (public viewing, free signup needed to modify/run).
I don't know the efficacy of this as an educational tool, but as a Python programmer, it's a really handy "cheat sheet" to have around whenever doing general scripting. It's really well written as well.
I would love a version of this that is incredibly comprehensive. I mean like, go over the entire Python doc in this format. Don't get me wrong, this goes over a lot, and but there's still a lot missing.
Yes, that is the same with or without parentheses. You're creating a tuple on the right-hand side of the equal sign, and using tuple unpacking on the left-hand side to assign the members of that tuple to variables. To make it a bit more clear, you can add parentheses on the left to match the ones on the right:
You get a list if you do "object_a = [1, 2, 3]" and a tuple if you do "object_b = (1, 2, 3)". Then try "object_c = 1, 2, 3" and you'll also get the tuple.
