Python Cookbook - Intro <ul>The  series  will give you solutions through: <li>Understanding of Python's language features
Implementations of common design patterns in Python </li></ul>
The Arsenal <ul><li>Specific solutions to specific problems
Python Language features
Design patterns
If you have a specific problem -
you know what to Google for!
What if you (think you) don't?
Better name for this series? Please tell me! </li></ul>
TODAY Confirming a need
Know your Python? <ul><li>Descriptor
Decorator
Generator
Iterator
Meta class
List comprehension </li></ul><ul><li>Lambda
Set
Queue
Upcoming SlideShare
Loading in …5
×

Danny Adair - Python Cookbook - Intro

1,788 views

Published on

as presented at the NZPUG meeting in Auckland, December 2008 - http://nzpug.org/MeetingsAuckland/Dec2008

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,788
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Danny Adair - Python Cookbook - Intro

  1. 1. Python Cookbook - Intro <ul>The series will give you solutions through: <li>Understanding of Python's language features
  2. 2. Implementations of common design patterns in Python </li></ul>
  3. 3. The Arsenal <ul><li>Specific solutions to specific problems
  4. 4. Python Language features
  5. 5. Design patterns
  6. 6. If you have a specific problem -
  7. 7. you know what to Google for!
  8. 8. What if you (think you) don't?
  9. 9. Better name for this series? Please tell me! </li></ul>
  10. 10. TODAY Confirming a need
  11. 11. Know your Python? <ul><li>Descriptor
  12. 12. Decorator
  13. 13. Generator
  14. 14. Iterator
  15. 15. Meta class
  16. 16. List comprehension </li></ul><ul><li>Lambda
  17. 17. Set
  18. 18. Queue
  19. 19. Threading
  20. 20. Closure
  21. 21. ... </li></ul>
  22. 22. Python Language Features <ul><li>Highlight what's available
  23. 23. How to use it
  24. 24. When to use it </li></ul>
  25. 25. How did you start Python? <ul><li>Early Pythonistas – Today's Pythonistas:
  26. 26. Still not the first language
  27. 27. Who are these people?
  28. 28. Veni, vidi, vici
  29. 29. “Reads like pseudocode” - why not have a deeper look, this seems too good to be true </li></ul>
  30. 30. Typical first Python <ul><li>List comprehensions
  31. 31. names = [p.name for p in people if p.age>20]
  32. 32. Exception Handling: Easier to ask forgiveness than for permission
  33. 33. (famous “is string representing an integer?”)
  34. 34. “There's only one way to do it”
  35. 35. (in a python interpreter, “import this” for the Zen) </li></ul>
  36. 36. <ul>“Perfection is not when there is no more to add, but no more to take away” - Antoine de Saint-Exupery </ul>How nice!
  37. 37. First problems, first pitfalls <ul><li>Indentation for some hard to get used to (can lead to catastrophic bugs)
  38. 38. Importing: a) from mymodule import *
  39. 39. b) relative/absolute/site-packages
  40. 40. Too general 'try...except:”
  41. 41. Standard library all over the show (PEP8 (2001) under_score/CamelCase, xmlrpc client/server (were) effectively incompatible...)
  42. 42. What others can you think of? </li></ul>
  43. 43. Minimalism is Appealing <ul><li>Knife
  44. 44. Bow
  45. 45. Green light
  46. 46. Rambo is ready to roll – bring it on!
  47. 47. Ready to roll? </li></ul>
  48. 48. Hang on... <ul>“Everything should be made as simple as possible, but not simpler.” - Albert Einstein </ul>
  49. 49. Why people ignore features <ul>Sad but true: Solely for practical reasons! <li>“No need, can do everything without it” (Rambo)
  50. 50. Existing codebase not using it, retrofitting a bi***
  51. 51. Production server running old Python (Remember “True = 1”?)
  52. 52. Core problems taken care of by library or framework (one result: Pythonic vs. Zopish)
  53. 53. “Too busy coding”! </li></ul>
  54. 54. Python Power Tools <ul>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 </ul>
  55. 55. NEXT <ul>Your vote! </ul>
  56. 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. 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. 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. 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 )

×