• Does not cover Structural Pattern Matching (the “match” and “case” keywords)². (EDIT: The FAQ states that it covers Python 3.8, and this feature was added in Python 3.10.)
• In my basic script template I have this, to show warnings by default:
if not sys.warnoptions:
import warnings
warnings.simplefilter("default")
• My basic script template also uses the “-bbI” switches to python on the shebang line.
Fantastic amount of information in a single page.
.
However there are two things I do not like:
1. Use of <identifier> notation for almost everything. It might be technically sound, but it brings to mind reading Backus-Naur form specs.
For cheat sheets my_int, my_iterator etc format is more pleasant for eyes.
2. Examples from various external libraries are of questionable real life utility, they are a nice showcase of what is possible, but are really too terse at times - looking at you popcorn audio example.
Official docs for libraries such as Plotly or Pandas are much more pleasant. Then again Copilot is even faster for looking up a tricky matplotlib incantation...
Thus the cheat sheet should have been split in two parts, one would cover Python and possibly standard library.
That is a lot of data for a single page IMO. You already have a TOC, several library sections might be pages unto themselves.
You might also cross link topics into their relevant python docs for deeper references. I know I always need to dig deeper into CSV/argparse for specific things when working with those systems.
At what point does something move from being a cheat-sheet to being a reference manual/training document? I don't have a hard definition other than the "you know it when you see it" and this cross that threshold for me.
A cheat-sheet I really like is https://devhints.io/bash which I feel has just enough info (for me) when jumping back into bash from other work to give me proper context.
For me the threshold is in the name: a cheat sheet must fit on 1-2 sheets of paper that you can stick to a wall or keep on desk without forming a pile. If it doesn't fit on paper it isn't a cheat sheet it is a reference. You can roughly apply the same guideline even digital format a chat sheet must fit 1-2 screens without scrolling.
I have nothing against references or this website as a reference those are useful as well. There is a value in having a good reference which strikes a balance of being exhaustive while avoiding the trap of unreadable verbosity that specifications and standards often have.
This comment got me thinking “What do you notice that is incorrect or important but missing from this page?” I discovered two things: 1) I’m too shallow in Python to identify any such issues and 2) while GPT-4 and Sage struggled with that precise question, in about 3 seconds I got what appears to be a really useful critique from Claude 2 100k. I’ll share that in case anybody is interested:
___
Here are a few things I noticed that could be improved on the Python cheatsheet page:
- The dictionary section is missing explanation of dict comprehensions. Dict comprehensions are an important and useful feature for constructing dictionaries in a concise way.
- In the section on modules, it would be good to mention virtual environments. Virtual environments are an important tool for Python dependency and package management.
- The examples in the Pandas section are useful, but more explanation or details could be provided on some of the core DataFrame operations like merging/joining, groupby, aggregations, etc.
- In the sections on concurrency and parallelism, async/await could be explained and demonstrated. Asyncio is commonly used for asynchronous programming in Python.
- The cheatsheet focuses mainly on built-in modules and functionality. It could be useful to also cover some widely used 3rd party libraries like NumPy, SciPy, Matplotlib, TensorFlow, etc.
- Sections on testing and debugging could be added - things like unittest, pytest, logging, debugging tools. Testing and debugging are key skills for Python developers.
- The cheatsheet is very text heavy. More visuals, diagrams, or tables could help make it more scannable and easier to navigate.
Overall it covers a lot of ground, but filling in some of those gaps would make it more comprehensive and useful as a reference. The content is excellent, just some ways it could be expanded on.
Eh. I think that critique misses more than it hits.
> The dictionary section is missing explanation of dict comprehensions. Dict comprehensions are an important and useful feature for constructing dictionaries in a concise way.
> In the sections on concurrency and parallelism, async/await could be explained and demonstrated. Asyncio is commonly used for asynchronous programming in Python.
> The cheatsheet focuses mainly on built-in modules and functionality. It could be useful to also cover some widely used 3rd party libraries like NumPy, SciPy, Matplotlib, TensorFlow, etc.
(It doesn't cover SciPy, Tensorflow. That said, I've been writing python for 23+ years, and can count on two fingers how many times I've needed either of those.)
----
Some parts of the critique are correct, if not especially useful IMO. I'd say most of the parts of the critique that are correct seem to misunderstand the purpose of the cheatsheet. The best points the model generated, IMO, were the ones related to pandas and virtual environments.
Thanks for the drill down. I should just searched the cheatsheet for each purportedly missing item. And I got a good chuckle picturing you counting “on two fingers” how many times you’ve needed SciPy or TensorFlow in 23 years!
Discoverability, a document like this makes it much easier to find features and tools you were unaware of. The Python documentation is awesome, but it doesn't provide a 30k ft overview of the language and standard library, especially when the standard lib is so comprehensive.
"Unofficial" documentation can serve needs that are neglected by the official docs, even if only by offering a different point of view. I can't speak to Python specifically, but to make an analogy, a microcontroller that I'm working with right now is documented by a 3500 page manual that requires a fair amount of expertise just to know what to look for. But a seasoned embedded dev might be just fine with that, and annoyed by anything simpler. On the other hand, I can make headway by using the Arduino API and boatloads of online documentation in the form of blogs, tutorials, StackOverflow, etc.
Likewise, nobody knows how to write technical documentation that's readable by everybody.
In the case of Python, the official docs are typically the last place where I'd look for stuff, given the quality of documents such as this cheat sheet. There's still a need for authoritative "developer" documentation, but not for me.
The diversity of Python developers, from hobbyists to pro's, justifies a similar diversity of documentation.
> In the case of Python, the official docs are typically the last place where I'd look for stuff, given the quality of documents such as this cheat sheet.
you say "I can't speak to Python specifically", but i can assure you that the official docs are far superior to this cheat sheet.
I can't read the entire python documentation in an hour. And having never taken a programming class or worked alongside a professional software engineer, I only know what it's occurred to me to look for. Python has lots of tools that I didn't know I needed. Probably the same us true for most people, and the only difference is what level of "cheatsheet" is appropriate.
I'm embarrassed to say I learned what generators are from this. 7 lines of code; totally unambiguous explanation. I don't even use iterators all that often, so I'm not surprised that I've never googled something that lead me to them.
personally I find online docs too bothersome. Over the years I've made an entire folder of cheatsheet org-mode files and when I work I can just hit a hotkey and grep them. Also writing and updating them actually helps memorize things
This is a good overview, thank you for sharing! One nitpick - the "duck type" section doesn't seem to mention Protocols, which is the "official" name you'll find in the Python documentation.
This is great, thanks Jure. For whatever reason I find it difficult to read documentation, I work much better with code examples, they speak to me much more clearly than a text explanation.
I think the online documentation for Python stdlib is quite good. What I don't understand is why more of it is not available in help() from Python itself. For all the docstring features in Python, the stdlib somehow just has second rate documentation in module and function docstrings!
Compare with numpy and scipy, where the docstrings are comprehensive (there's a correspondance between online and embedded docs.)
Difficult to read and lacks a page layout for printing. It should've used font and style variations for placeholders rather than nonstandard and annoying characters like < >.
this reminds me of the perlrefs I used to download and printout; despite having years of perl coding, I'd often forget which combinations of @#$%^&* (ok I'm just randomly typing now!) I'd have to use.
I asked it to generate something similar for golang with a snippet of the list section, and the results look pretty similar. So I don't think it's relying too heavily on a direct example.
I highly highly highly recommend using something like Zeal for documentation viewing. It's so much faster to type in something and read docs than to google, no matter how fast your internet is. Though it's more limited to knowing what object you're looking for already
(The first person to mention ChatGPT gets bopped. I do not need to use an LLM to look up module documentation)
See also:
* Python Crash Course cheatsheet: https://ehmatthes.github.io/pcc_3e/cheat_sheets/
* Scientific Python cheatsheet: https://ipgp.github.io/scientific_python_cheat_sheet/
* Common beginner errors: https://pythonforbiologists.com/29-common-beginner-errors-on...
* Python regular expression cheatsheet: https://learnbyexample.github.io/python-regex-cheatsheet/ — my blog post, includes examples as well