The Home for People Who Like to Flip Out and Write Code
Notes From PyATL 2011-12-08
An Example Python Program (Brandon Rhode)
- If I ever need to do PDFs in Python, I should look into
- Lots of emphasis on PyFlakes, but I’m already a
git Commits (Kelsey Hightower)
- The Prime Directive of commits: group logical changes together.
- Here’s a good tip: describe the behavior before and after the patch
- If you have your tests in a different commit, you should note that in the
Using Code for Configuration (JR Rickerson)
- typed data
- easy-to-read data structures
- no extra parsers
- The Django config file is used as an example
- The board positions example was a very good choice
- Cons from the Q and A:
Python, Linkers, and Virtual Memory (pre-alpha version; Brandon Rhodes)
- The talk starts with a pretty cool oral history of the group, and personal
anecdotes from Brandon. He’ll be missed.
- Ah, the joys of virtual memory…
- Text Segment is where your actual, binary program resides
- Data Segment is the heap
- And (thankfully) modern systems have permissions built into them so data
isn’t leaked/stomped between processes, etc.
- It’s cool that the Text Segment for an executable can be shared, along
with the dynamic libraries
- Process do get their own working RAM
fork() FTW! Nothing like a little
COW. The only difference between
parent and child is the page that differentiates the parent from the
- Other tricks: shared executables/libraries, swap, and caching.
- Bumps in the Road:
- Dynamic linking: version mismatches can give you the “undefined symbol”
error. Static linking works around it at the cost of increased memory
pyzmq-static for a case study.
- The little page-table diagrams make it abundantly clear why it’s hard to say
exactly how much memory a program is “using”.
- RAM is an illusion: binaries, executables, swap, duplication are all part
of the problem
- Dynamic linking saves RAM at the risk of errors
- Deciding how much memory a process is actually using is hard