...

• Removing commented out code - Yes or No?  YES!!
• G30: Functions should do one thing
• Creating a Coding Standard Convention Wiki
  • Find terminology used throughout the book that we want to use to identify.
  • Make sure we don't get too jargony - that it makes it hard for newcomers to come up to speed.
  • Make sure PR reviewers still continue to explain themselves rather than just throw out a term.
  • Hyperlinkable sections.
  • Create a confluence wiki - contributor guidelines.
• Action Items:
  
  • Order "Effective Python" Cliff Dyer (Deactivated)
  • Invite all of Eng to club Cliff Dyer (Deactivated)
  • Ping IT on creating Github team Christopher Lee (Deactivated)
  • Create wiki for coding convention Nimisha Asthagiri (Deactivated)

March 30, 2016

Effective Python: Chapter 1 & 2

• Item 2:
  
  • double-underscore is not for private variables.
• Item 3:
  • How to handle native strings?
    • from __future__ import unicode_literal & silence when needed (variable behavior between files (yuck))
    • lint native strings
    • have coercion functions
  • Needs engineering education
• Item 5: slice
  • Is it bad that it is forgiving?
    • Sometimes it's useful
    • Maybe there should be a failfast version.
• Item 10: enumerate
  • Very useful
  • Takes initial index!  Cool!
• Item 11: zip
  • Makes Akiva nervous, because it has weird behavior with different length strings
  • zip_longest does the longer one (padding with Nones)
• Item 12:
  • Renzo disagrees
  • should we avoid else blocks.
  • "If a feature is rare and somewhat surprising, you shouldn't use it." – Akiva
  • Alternative is good: break loop out into a separate function
  • Use with comment to describe behavior.
• Item 14: Avoid None
  • not var is a source of bugs because None and 0 are both false
  • It's fairly useful for containers (lists, dicts, strings, etc.)
• Item 15: Closures
  • Accessing non-locals: create a class
  • Use nonlocals as read only
• Item 16: consider generators instead of lists
  • small lists are fine
  • generators can be problematic.  See Item 17.
  • we don't do much of this
  • generators are awesome
  • custom containers are awesomer
• Item 17: be defensive when iterating over sequences twice.
  
  • iter(foo) is iter(foo)
    
    • different from iter(foo) is foo?
  • convert to list if you hit this kind of error and don't want to refactor into a custom container.
• Item 21: keyword only args
  
  • Nimisha does not recommend using **kwargs to enforce keyword-only args, because it makes the code ugly and hard to read
    • Sometimes it's useful anyway

Not Discussed:

• Item 1: Know which version of Python you're using
• Item 4: Write helper functions instead of complex expressions
• Item 6: avoid using start, end, and stride in a single slice
  • I think we did discuss this, at least obliquely.  I didn't capture notes.
• Item 7: Use list comprehensions instead of map and filter
• Item 8: Avoid more than two expressions in list comprehensions
• Item 9: Consider generator expressions for large comprehensions
• Item 13: Take advantage of each block in try/except/else/finally
• Item 18: Reduce visual noise with variable positional arguments
• Item 19: Provide optional behavior with keyword arguments
• Item 20: Use None and docstrings to specify dynamic default arguments