guido van rossum guido@python.org th laser summer school...

Guido van Rossumguido@python.org

9th LASER summer school, Sept. 2012

Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

  A dynamic programming language   A successful open source project   A vibrant community of software developers   A tool used daily by thousands of scientists   A popular system for web app development   A versatile scripting tool   A way to have fun while programming

$ python3

Python 3.3.0b2+ (default:dc18d73e67a5, Aug 17 2012, 14:20:29)

[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

>>> print('Hello world')

Hello world

>>> def fact(n):

... if n <= 1:

... return 1

... return n * fact(n-1)

...

>>> fact(40)

815915283247897734345611269596115894272000000000

>>> print(fact)

<function fact at 0x10067c830>

>>>

class Indexer: """Construct a map of words -> locations."""

def __init__(self): # constructor self.words = {}

def add_word(self, word, location): word = self.normalize(word) if word not in self.words: self.words[word] = set() self.words[word].add(location)

punctuation = ',;:.\'"!?()' # class variable

def normalize(self, word): return word.lower().strip(self.punctuation)

def merge(self, other): for word, locations in other.words.items(): if word not in self.words: self.words[word] = set() self.words[word].update(locations)

  Simple keywords (e.g. class, def, if, not)   Indentation for statement grouping   Distinguishes expressions from statements   Conservative use of punctuation   Borrows more from C than you'd think   No type declarations   Things aren't always what they appear   Compiler is stupid by design   The only thing static is scope of variables

  Everything is dynamic   Everything is an object   Classes are objects, too   Everything can be printed   Everything is introspectable   Some objects are immutable   The compiler is always available   Memory management is automatic   Bytecode is an implementation detail   Objects may be implemented in native code

  Immutable: null, bool, int, float, str, bytes, tuple ◦  None, True, 42, 3.14, 'abc', b'abc', ('foo', 'bar', 123)

  Mutable: list, dict, set, bytearray ◦  [1, 2, 3], {'a': 1, 'b': 2}, {1, 2, 3}, bytearray(b'abc')

  Code: module, class, function, exception   Specialized: property, static/class method   Other: code, descriptor, bound method, ...   Many other more obscure types exist   User-defined classes are types, too   Introspection reveals a type's properties

  E.g. constructors, operators, iterators   class Foo:

def __init__(self): ... # constructor def __new__(cls): ... # immutable c'tor def __add__(self, other): ... # operator def __iter__(self): ... # iteration def __foobar__(self): ... # custom protocol def bar(self): ... # regular method def _bar(self): ... # "protected" method def __bar(self): ... # "private" method

  Always available   Too much to even summarize   Additional data types, protocols   Algorithms and data structures   Operating system services   Internet, web, standards   Testing, debugging, profiling, development   Python runtime APIs, introspection

  23659 packages available on PyPI.python.org   Web frameworks (100s of them! :-)   Database drivers (Oracle, MySQL, Postgres, ...)   NumPy / SciPy (a whole ecosystem)

  Python Software Foundation (PSF)   PyCon, EuroPython, PyCon {UK,DE,ZA,BR,...}   PyRu, DjangoCon, SciPy, ...   Local user groups, PyLadies, ...   {www,docs,pypi,mail,bugs,hg,...}.python.org   {python-dev,python-list,python-announce,

python-ideas,core-mentors}@python.org   web-sig, import-sig, stdlib-sig,*-sig, ...   Python books

  Coordinated via python-dev@python.org   Rough organization: BDFL, release managers,

area experts, developers, contributors   ~80 active developers (committers)   300-1200 (!) emails/month on python-dev   15+ checkins/day   ~50 bugs/week opened, ~50 fixed/closed   1618 .py files, 479 .c, 263 .h, 429 .rst, 280 dirs   309 PEPs (144 final, 8 accepted, 20 active, 24 draft, 19 deferred,

21 withdrawn, 4 superseded, 67 rejected, 1 april fool)

  "Feature" releases: every 18-24 months ◦  2-4 alphas, 2-4 betas, 1-2 rel. candidates

  "Bugfix" releases: every 3-6 months ◦  Strict backward compatible requirement

  Currently active feature releases: 2.7, 3.2 ◦  Next feature release: 3.3 (last released: 3.31rc1)

  API deprecation takes 1-3 feature releases   "Once in a decade" releases: 2.0, 3.0, ...

  a.k.a. Py3k, Python 3   First mention around 2000 (as a joke)   Work started for real in 2006   3.0 released December 2008   3.1 released June 2009   3.2 released February 2011   3.3 to be released September 2012

  Python 4000: after my retirement

  Monty Python references   Easter eggs (import this, antigravity)   April Fool announcements and PEPs   PyCon 2012: 5k run, robot dance   Lightning talks   PyWeek game programming contests

  From ABC to Python ◦  a history lesson

  Python's Meta-Object Protocol ◦  a deep dive

  From Iterators to Generators ◦  more history

  Asynchronous I/O ◦  a problem with competing solutions

  Static Analysis ◦  an as yet unsolved problem