9 ms·

Best Python Reference Ever

120 points by pizzaburek 7y ago

meowface 7y ago
Don't think I'd ever use this, but this was new to me: >To dynamically access function's first free variable use '<function>.__closure__[0].cell_contents'.
seemslegit 7y ago
The <thing> notation is pretty confusing and I find myself using my knowledge of python to understand what half of the examples are teaching rather than the other way around.
FZ1 7y ago
A key hallmark of Python is readability - which this cheat sheet has managed to royally screw up. It looks more like an XML cheatsheet at first glance. I work in python full-time for a living, and found myself having to re-examine several times to make sense of this wacky, non-standard notation. ------- Edit: Keep in mind there's a standard way to represent these options in a clear, consistent manner (lists, sequences, optional args). No need to re-invent something that's hard to read and understand. See: https://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range https://docs.python.org/3/library/stdtypes.html#sequence-typ...
- Lendal 7y ago
  I think this is for people who already know Python, and just need a quick memory aid. I agree for a complete and correct reference I would recommend the documentation, as you said. A proper cheatsheet takes liberties for the sake of achieving both brevity and comprehensiveness at the same time.
- wyattpeak 7y ago
  While I agree the notation is a bit weird, I disagree that there is any standard notation for types. The Python docs in particular fail for exactly one of the things I like about TFA - it tells you the type of the output of each function in its angle-bracketed style. Take, for example, the definition of the operation s[i:j] in the Python docs: the result is "slice of s from i to j". Is that the same type as the input? Is it an iterator? No information. I doubt most people are confused about the output, but a reference is specifically for people who are uncertain about how a function works.
  - FZ1 7y ago
    You're right that there is not any official standard. But almost every major library follows a convention that's very similar to the cpython docs. If you're making a language reference, shouldn't it look like the language ?
- nixpulvis 7y ago
  the hallmark is readability?! really!? Please explain to me why then you introduce a binding after you use it in array comprehensions. [x*2 for x in range(1,10)]
  - pyuser583 7y ago
    Functional programming?
    - nixpulvis 7y ago
      I wouldn't call this a functional argument, per se, although many functional languages encourage the kind of syntax I'm advocating for here. And some may not... Basically I write things like `data.map(|x| ...).filter(|x| ...)`, or just `data.fold(|x| ...)` and I'm quite happy.
  - vharuck 7y ago
    As a person who majored in math, this is very readable.
    - nixpulvis 7y ago
      As a person who often struggled in math for perhaps many reasons, this was a common issue for me. First you define things, then you use them. No other rule makes sense generally, and I challenge anyone to prove me wrong. Now is a simple set like { 2x : x ∈ ℝ } going to confuse me, probably not... but when variables are just thrown around all willy nilly, I get confused pretty quick.
    - saeranv 7y ago
      I never understood list comprehensions, and was always slightly resentful of (in my mind) their illogical ordering until I realized they were mimicking mathematical expressions.
  - Igelau 7y ago
    In one of your math courses you'll eventually run across what they call "set builder notation. The notation for this is a decent example that shouldn't be too hard to follow. What it's basically saying is {2x: x∈[1,10)} with the implication that x is an integer. We usually read the colon (or sometimes a vertical bar) as "such that". I know my explanation is somewhat lacking, but you can probably see the parallels there. You'll probably get to it this year or next.
siquick 7y ago
Great resource >> <list>.append(<el>) # Or: <list> += [<el>] Not a fan of the += syntax in this instance - seeing .append instantly lets me know I'm dealing with a list whereas += can be used on almost anything
gjm11 7y ago
Seems like a needlessly editorialized title. (The actual title at the far end of the link is "Comprehensive Python Cheatsheet".)
saeranv 7y ago
I use Python full time and I found this useful. Starred it for future reference. Why does everyone find the <thing> notation confusing? <list> means its a list, and so on. I'm really surprised it's tripping people up.
umvi 7y ago
"Basic Mario Brothers Example" This needs to be a thing for every programming language cheatsheet
strogonoff 7y ago
A good way of specifying variable types in sample code is with Python’s native type hint syntax[0]. Using angle brackets is an option, but it results in invalid syntax (confusing to beginner programmers) and is used by languages such as TypeScript and Swift to signify generics (confusing to established engineers coming from those languages). [0] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html

120 points by pizzaburek 7y ago

Don't think I'd ever use this, but this was new to me: >To dynamically access function's first free variable use '<function>.__closure__[0].cell_contents'.

seemslegit 7y ago

The <thing> notation is pretty confusing and I find myself using my knowledge of python to understand what half of the examples are teaching rather than the other way around.

FZ1 7y ago

A key hallmark of Python is readability - which this cheat sheet has managed to royally screw up. It looks more like an XML cheatsheet at first glance. I work in python full-time for a living, and found myself having to re-examine several times to make sense of this wacky, non-standard notation. ------- Edit: Keep in mind there's a standard way to represent these options in a clear, consistent manner (lists, sequences, optional args). No need to re-invent something that's hard to read and understand. See: https://docs.python.org/3/library/stdtypes.html#sequence-types-list-tuple-range https://docs.python.org/3/library/stdtypes.html#sequence-typ...

Lendal 7y ago
I think this is for people who already know Python, and just need a quick memory aid. I agree for a complete and correct reference I would recommend the documentation, as you said. A proper cheatsheet takes liberties for the sake of achieving both brevity and comprehensiveness at the same time.
wyattpeak 7y ago
While I agree the notation is a bit weird, I disagree that there is any standard notation for types. The Python docs in particular fail for exactly one of the things I like about TFA - it tells you the type of the output of each function in its angle-bracketed style. Take, for example, the definition of the operation s[i:j] in the Python docs: the result is "slice of s from i to j". Is that the same type as the input? Is it an iterator? No information. I doubt most people are confused about the output, but a reference is specifically for people who are uncertain about how a function works.
- FZ1 7y ago
  You're right that there is not any official standard. But almost every major library follows a convention that's very similar to the cpython docs. If you're making a language reference, shouldn't it look like the language ?
nixpulvis 7y ago
the hallmark is readability?! really!? Please explain to me why then you introduce a binding after you use it in array comprehensions. [x*2 for x in range(1,10)]
- pyuser583 7y ago
  Functional programming?
  - nixpulvis 7y ago
    I wouldn't call this a functional argument, per se, although many functional languages encourage the kind of syntax I'm advocating for here. And some may not... Basically I write things like `data.map(|x| ...).filter(|x| ...)`, or just `data.fold(|x| ...)` and I'm quite happy.
- vharuck 7y ago
  As a person who majored in math, this is very readable.
  - nixpulvis 7y ago
    As a person who often struggled in math for perhaps many reasons, this was a common issue for me. First you define things, then you use them. No other rule makes sense generally, and I challenge anyone to prove me wrong. Now is a simple set like { 2x : x ∈ ℝ } going to confuse me, probably not... but when variables are just thrown around all willy nilly, I get confused pretty quick.
  - saeranv 7y ago
    I never understood list comprehensions, and was always slightly resentful of (in my mind) their illogical ordering until I realized they were mimicking mathematical expressions.
- Igelau 7y ago
  In one of your math courses you'll eventually run across what they call "set builder notation. The notation for this is a decent example that shouldn't be too hard to follow. What it's basically saying is {2x: x∈[1,10)} with the implication that x is an integer. We usually read the colon (or sometimes a vertical bar) as "such that". I know my explanation is somewhat lacking, but you can probably see the parallels there. You'll probably get to it this year or next.

siquick 7y ago

Great resource >> <list>.append(<el>) # Or: <list> += [<el>] Not a fan of the += syntax in this instance - seeing .append instantly lets me know I'm dealing with a list whereas += can be used on almost anything

gjm11 7y ago

Seems like a needlessly editorialized title. (The actual title at the far end of the link is "Comprehensive Python Cheatsheet".)

saeranv 7y ago

I use Python full time and I found this useful. Starred it for future reference. Why does everyone find the <thing> notation confusing? <list> means its a list, and so on. I'm really surprised it's tripping people up.

umvi 7y ago

"Basic Mario Brothers Example" This needs to be a thing for every programming language cheatsheet

strogonoff 7y ago

A good way of specifying variable types in sample code is with Python’s native type hint syntax[0]. Using angle brackets is an option, but it results in invalid syntax (confusing to beginner programmers) and is used by languages such as TypeScript and Swift to signify generics (confusing to established engineers coming from those languages). [0] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html