Recommended
More Related Content
Similar to PEP Presentation for PythonKC
Recently uploaded
Recently uploaded (20)
PEP Presentation for PythonKC
- 2. Zen of Python (PEP 20) 2
- 4. BeauLful is be"er than ugly h"p://www.dailystab.com/blog/wp-‐content/uploads/2009/06/ugly.jpg 4
- 5. Explicit is be"er than implicit h"p://cache2.artprinLmages.com/p/LRG/19/1922/GWT9D00Z/art-‐print/parental-‐advisory-‐explicit-‐lyrics.jpg 5
- 6. Simple is be"er than complex h"p://musikality.net/wp-‐content/uploads/simplicity.jpg 6
- 7. Complex is be,er than complicated h"p://vipdicLonary.com/img/life_geXng_complicated.jpg 7
- 8. Flat is be"er than nested h"p://3.bp.blogspot.com/_L1y4XexY16s/S_0WXArDtWI/ AAAAAAAAVU0/oUjxL8kI0iY/s1600/NestedDoll0.jpg 8
- 9. Sparse is be"er than dense h"p://www.pitch.com/imager/come-‐october-‐royals-‐dont-‐need-‐all-‐those-‐seats/b/original/ 2568438/9885/Empty_seats_at_the_Royals_game_thumb.jpg 9
- 11. Special cases aren't special enough to break the rules. h"p://www.hornblend.com/wp-‐content/uploads/2010/08/duh.jpg 11
- 12. Although pracLcality beats purity. h"p://vilain.net/files/pracLcality.jpg 12
- 13. Errors should never pass silently. h"p://media02.hongkiat.com/funny_error_messages/funny-‐bsod-‐02.jpg 13
- 15. In the face of ambiguity, refuse the tempta>on to guess. h"p://www.doublejourney.com/wp-‐content/ambiguity.jpg 15
- 16. There should be one-‐-‐ and preferably only one -‐-‐obvious way to do it. h"p://www.motorcycles-‐ok.com/mokpics/x/obvious.jpg 16
- 17. Although that way may not be obvious at first unless you're Dutch. Dutch Flag h"p://ew.cachefly.net/snm/images/nm/flags/nl-‐lgflag.gif 17
- 18. Now is be"er than never. h"ps://lh6.googleusercontent.com/_zGnH6HWaAi0/TY_3ysjUkOI/AAAAAAAAKSI/S168q0DA9vs/never_regret.jpg 18
- 19. Although never is oFen be,er than *right* now. Why, Eddie? h"p://idioelashback.files.wordpress.com/2010/02/van_halen_logo.jpg 19
- 20. If the implementa>on is hard to explain, it's a bad idea. h"p://img256.imageshack.us/img256/8379/magnets.jpg 20
- 21. If the implementa>on is easy to explain, it may be a good idea. h"p://images.cheezburger.com/completestore/2011/6/11/6c21f0de-‐4f50-‐4194-‐94bd-‐10ba19b77d8f.jpg 21
- 22. Namespaces are one honking great idea -‐-‐ let's do more of those! h"p://1.bp.blogspot.com/_GfY7dNRDwYI/TUHlJyG7YKI/AAAAAAAAArU/yk-‐RtF96ZWM/s1600/ponies-‐and-‐rainbows.jpg 22
- 23. PEP 8 Why a Style Guide matters. 23
- 25. What is a Style Guide? h"p://intheknow.lordandtaylor.com/tag/fall-‐2011/ 25
- 26. SecLons • Lay-‐out • Imports • Whitespace • Comments • Document Strings • Version Bookkeeping • Naming Conven>ons • Programming Recommenda>ons 26 26
- 27. Lay Out • 4 spaces – Unless you’re working on some old stuff that is already using 8 spaces • Ver>cal Alignment – Either align with opening delimiter – Or use extra indenta>on 27
- 28. Lay Out • Tabs and Spaces – Never mix the two (like liquor and beer) – If in doubt, go with spaces, only. • Maximum Line Length – 79 char. – Use the implicit line wrap within parenthesis 28 28
- 30. Lay Out • Blank Lines – 2 lines between top level func>on and class defini>on – Use blank lines to logically group sec>ons – It’s not MLA. Don’t double-‐space your code. • Encodings – Core code = ASCII or La>n-‐1 – Code > 3.0 should use UTF-‐8 30 30
- 31. Lay Out 31
- 32. Imports • One import per line • Put at the top of the document aFer comments and doc strings – First Standard Library – Then related third-‐party imports – Last, applica>on / library specific imports 32
- 33. Whitespace Too much is too much. h"p://www.alistapart.com/d/whitespace/whitespace.jpg 33
- 34. Whitespace • Don’t get cute and add whitespace within parenthesis or brackets, around binary operators. – Write it how you would normally write it • Do use spaces around arithme>c operators – Math is hard as it is, don’t make it harder my squishing things together... 34 34
- 35. Whitespace • Don’t put compound statements on one line. • Spread that stuff out so it is easy to find the various clauses and stuff. 35 35
- 36. Comments • Comments should match the code. • If there is a conflict, change one of them! • Comments should be complete sentences, wri,en in English. • Lean towards using block comments. • Use inline comments sparingly. • Don’t be the obvious troll. 36
- 37. Doc Strings • Use them! • PEP 257 h"p://catmacros.files.wordpress.com/2010/05/itoldyouno"odothat.jpg 37
- 38. Naming ConvenLons • Single Lower (d) • Single Upper (W) • lowercase • lower_with_underscore • UPPERCASE • UPPER_WITH_UNDER • CamelCase • mixedCase 38
- 39. Naming ConvenLons • Avoid: – ‘l’, ‘O’, ‘I’ • Modules should be short, lowercase • Classes in CamelCase • Func>ons should be lower_with_underscores • Constants should be UPPER_WITH_UNDER 39 39
- 40. Programming RecommendaLons • Thing about the other guys. • Don’t use equality when comparing singletons • “if X is not None” is not the same as “if X” 40