2016 - Raymond Hettinger - Keynote - Core Developer World

Keynote
All levels, Python Fundamentals
​
What I've learned from being a maintainer and core developer for the past 15 years. Thoughts on channeling Guido, stability, hyper-generalization, Sturgeon's law and egativity, evaluating submissions, inability to predict the future, user centric design, treating mature code differently, believing in or doubting your predecessors, lever arguments and completers, problems of too many choices, implementation details, how much to document, needs of the standard library versus the needs of users, code that is dead on arrival and how PyPI changed everything, orthogonality, importance of skill and expertise, consistency and foolish consistency, optimization and premature optimization, security tautologies, argument ordering, operator abuse, avoiding race to implementation (we can all write working code), the naming of parts, economy of force and complexity balance, feature creep, developing for others, over reliance on Guido, great minds don't think alike, preference for compactness, and aversion to deprecations. What it means to be completely reliant on long term unpaid
volunteers.

Bio
Raymond has been a prolific contributor to the CPython project for over a decade, having implemented and maintained many of Python's great features. He has been instrumental in modules like bisect, collections, decimal, functools, itertools, math, random, with types like namedtuple, sets, dictionaries, and in many other places around the codebase. He has contributed to the modification of nearly 90,000 lines of code in the CPython repository, and has made over 160 changes in the PEP repository.
Raymond has also served as a director of the Python Software Foundation, and has mentored many people over the years on their contributions to the python-dev community. He's also well known for his contributions to the Python Cookbook, and shares many pieces of Python wisdom on Twitter. He received the Distinguished Service Award at PyCon 2014 for his exceptional contributions to the python community.
​

Transcript

1. Core Developer World Raymond Hettinger @raymondh PyBay 2016
2. Adventures in Open Source   Once upon a time, I boarded a train in Shaghai …   Peter Norvig used my code, so did CERN.   My code is on your t-shirt!   Would you like to give a keynote in Moscow?   At what temperature do you incubate Python eggs?
3. We’re hiring!   Diverse developers wanted.   Build software that changes the world   Work from home on a collaborative distributed team   No limits on how many hours you work   Free to select any subproject that interests you   Salary doubles every year!
4. What you can do   Add docstrings to the ElementTree package   Review the CompactDict (27350)   Improve Error Reporting (watch users)   Make IDLE a Credible Editor (27771)   Weigh-in on whether proposals are good are bad (26988, 27754, 12345)   Help Design an API (18844)
5. Hone your management skills We consider that a Python developer should know about these nearly infinite possibilities, because it instills confidence that no impassable problem will be on the way. However, knowing how and particularly when not to use them is very important. Like a kung fu master, a Pythonista knows how to kill with a single finger, and never to actually do it. -- Kenneth Reitz
6. Be a good neighbor   Don’t trample other people’s flower gardens (collections, random, itertools, enum)   Don’t be a picture straightener (change subset test to assertLessThan)   Don’t be a weirdo (self-censor your crazy ideas)   Don’t be too chatty on a maillist (bandwidth is finite)   Don’t rush to make a patch (this is the least important part of contributing)
7. Finding your way   Work on the big problems (problems people actually have)   Assume the people who came before you knew what they were doing   Spend a lot of time thinking about the world from a user point of view (you are atypical and Python is not for you)   Set out on a journey to discover deep zen and harmony
8. Anchor yourself and Python Spend time thinking about what you like best about the language, what other people like best, and what makes the language so successful. Then commit yourself to not changing those parts and gently redirect others who would undermine the secret sauce while working on other problems. The greatness of the language is not a given. Harmony is fragile.
9. Thinking positively   When reviewing feature requests, remember Sturgeon’s Law. 10% of everything might be a good idea.   Inside every bad idea is the germ of a good idea. Find a way to nurture that. (pypi, aspn recipes, core issue)   Remember that core devs are volunteers and that time is their most precious resource   The thesis of Walden Pond suggests that giving users fewer choices improves their lives.
10. More anchoring A general purpose programming language is a vast ocean and it is easy to get caught in a swirl of contrived problems. Let real world use cases be your compass. Resist the urge to be too cute. Resist lever arguments. Uncle Timmy teaches us that practicality beats purity. Our whole profession boils down to management of complexity. Each feature request needs to be evaluated in terms of whether it results in a net increase or decrease in complexity.
11. Lessons from CDW   Security tautologies (if I’m on the inside, I could get on the inside).   Operator abuse (pyparsing, iterator pipes, …)   Order of arguments to match existing functions, to help partial, to read well with long inputs (accumulate)   The phrase, “it might be nice if”, is a contraindication   Python is bigger than any one individual. Accept that you will not ever know everything that is relevant.
12. Lessons from CDW   Stay true to a module’s original purpose   To make some thing successful, you don’t need to first make something else unsuccessful.   Mature, deployed code is sacred. Stability can be more important the refactoring.   The needs of the many (users) outweigh the needs of the few (the standard library itself)
13. Unittests are sacred and fragile   Tests protect code against mis-refactorings   The tests themselves have no such defense   Test driven development and regression tests are special, because at one time they failed.   Tests reflect the author’s unique viewpoint and understanding assertTrue(set(a) <= set(b)) assertLessThanEqual(set(a), set(b))
14. Case Study: Hypergeneralization str.index(sub [,start [,end]]) str.rindex(sub [,start [,end]]) str.find(sub [,start [,end]]) str.rfind(sub [,start [,end]]) str.startswith(prefix) str.endswith(prefix)
15. Case Study: AutoEnum class Color(AutoEnum): red green blue class AddressType(AutoEnum, ignore='classmethod staticmethod'): pobox mailbox property
16. Case Study: Tau >>> import math >>> math.pi 3.141592653589793 >>> math.tau 6.283185307179586
17. Case Study: assertIsClose self.assertIsClose(math.pi, 355 / 113)
18. Case Study: invert bool >>> a | b True >>> a & b False >>> ~a -2
19. Case Study: str.format format(value[, format_spec]) printf(format_spec, value)