Danny Adair - Python Cookbook - Intro
- 1. Python Cookbook - Intro The series will give you solutions through: Understanding of Python's language features
- 2. Implementations of common design patterns in Python
- 3. The Arsenal Specific solutions to specific problems
- 6. If you have a specific problem -
- 7. you know what to Google for!
- 8. What if you (think you) don't?
- 9. Better name for this series? Please tell me!
- 10. TODAY Confirming a need
- 11. Know your Python? Descriptor
- 12. Decorator
- 13. Generator
- 14. Iterator
- 15. Meta class
- 17. Set
- 18. Queue
- 19. Threading
- 20. Closure
- 21. ...
- 22. Python Language Features Highlight what's available
- 23. How to use it
- 24. When to use it
- 25. How did you start Python? Early Pythonistas – Today's Pythonistas:
- 26. Still not the first language
- 27. Who are these people?
- 28. Veni, vidi, vici
- 29. “Reads like pseudocode” - why not have a deeper look, this seems too good to be true
- 30. Typical first Python List comprehensions
- 31. names = [p.name for p in people if p.age>20]
- 32. Exception Handling: Easier to ask forgiveness than for permission
- 33. (famous “is string representing an integer?”)
- 34. “There's only one way to do it”
- 35. (in a python interpreter, “import this” for the Zen)
- 36. “Perfection is not when there is no more to add, but no more to take away” - Antoine de Saint-Exupery How nice!
- 37. First problems, first pitfalls Indentation for some hard to get used to (can lead to catastrophic bugs)
- 38. Importing: a) from mymodule import *
- 41. Standard library all over the show (PEP8 (2001) under_score/CamelCase, xmlrpc client/server (were) effectively incompatible...)
- 42. What others can you think of?
- 43. Minimalism is Appealing Knife
- 44. Bow
- 45. Green light
- 46. Rambo is ready to roll – bring it on!
- 47. Ready to roll?
- 48. Hang on... “Everything should be made as simple as possible, but not simpler.” - Albert Einstein
- 49. Why people ignore features Sad but true: Solely for practical reasons! “No need, can do everything without it” (Rambo)
- 50. Existing codebase not using it, retrofitting a bi***
- 51. Production server running old Python (Remember “True = 1”?)
- 52. Core problems taken care of by library or framework (one result: Pythonic vs. Zopish)
- 54. Python Power Tools I had my power drill slung low on my toolbelt and I said,“Go ahead, honey. Break something.” - Tim Allen on the challenges of figuring out what to do with a new set of general-purpose tools
- 55. NEXT Your vote!
- 56. Tips & Tricks Often you need one little piece of information, and no one is to blame it's not there. Some things just... need some help
- 57. Setting the Name of a Function If an outer function just returns an inner function (often a closure), the name of the returned function object is fixed, which can be confusing when the name is shown during introspection or debugging: >>> def make_adder(addend): … def adder(augend): return augend+addend … return adder … >>> plus100 = make_adder(100) >>> plus_23 = make_adder(23) >>> print plus100(1000), plus_23(1000) 1100 1023 >>> print plus100, plus_23 <function adder at 0x386530> <function adder at 0x3825f0>
- 58. Python 2.4+ You can solve the problem by setting the __name_ attribute of the inner function before returning it: def make_adder(addend): def adder(augend): return augend+addend adder._name__ = 'add_%s' % (addend, ) With this change the output becomes more useful: >>> print plus100, plus_23 <function add_100 at 0x386530> <function add_23 at 0x3825f0>
- 59. Python 2.3 Unfortunately, the __name__ attribute is read-only in this release. The same effect is achieved by constructing a new function object which differs from the other only in name: import new def make_adder(addend): def adder(augend): return augend+addend return new.function( adder.func_code, adder.func_globals, 'add_%s' % (addend,), adder.func_defaults, adder.func_closure )