1. The State of the Python Union BDFL Keynote @ PyCon – March 24, 2005 Guido van Rossum Elemental Security, Inc. guido@elementalsecurity.com guido@python.org

2. March 24, 2005© 2005 Guido van Rossum 2 Elemental Security, Inc. Enterprise security software cross-platform policy compliance reporting and enforcement Startup in stealth mode public launch April 5th! Using lots of Python We're always hiring! See http://www.elementalsecurity.com

3. March 24, 2005© 2005 Guido van Rossum 3 Why my Keynotes Suck

4. March 24, 2005© 2005 Guido van Rossum 4 What's With the Beard? Started with a "beta [crunch] beard"; but then: "The authors of others script languages have no moustaches. Ruby and the Python is better, than Perl, but meet where less often than Perl. There is, however, a hope for Van Rossum, suddenly will grow a beard. It is not necessary to count on Mr. Matsumoto - at Japanese the beard grows badly. " –http://khason.biz/blog/2004/12/why-microsoft-can-blow-off-with-c.html cached at: http://purec.binghua.com/Article/Class17/Class22/200412/386.html At Elemental I'm now called "professor"

5. March 24, 2005© 2005 Guido van Rossum 5 Decorators Redux Remember last year's keynote? –5 variations splicing [decorator,...] into a def [deco] def name():... // def [deco] name(): //... def name [deco] ():... // def name() [deco]: //... def name(): [deco]... So what happened? How did @deco win? –It's the one that everybody dislikes equally :-) –It's unambiguous and uses prefix syntax –Java 1.5 has similar syntax Why is it so controversial? –If you can handle __init__, why is @deco so bad? –Get over the Perl similarity already!

6. March 24, 2005© 2005 Guido van Rossum 6 Why No Class Decorators? Superfluous given metaclasses The need to be at near the top is easily met without adding new syntax May be revisited if someone cares enough –needs motivating use cases / examples

7. March 24, 2005© 2005 Guido van Rossum 7 Python's Growing Popularity 14% (from 8%) – InfoWorld survey (Sept '04) –"But the big winner this time around is the object- oriented scripting language Python, which saw a 6 percent gain in popularity, almost doubling last year's results. " www.infoworld.com/article/04/09/24/39FErrdev_1.html Burton Group report on "P-languages": –"Both Perl and Python have been used in application development and for limited integration, but it appears that Python is a better fit for this domain for several reasons. Python is easy to learn, fully functional, syntactically clean, and very modular. " Report available for $$ via www.burtongroup.com

8. March 24, 2005© 2005 Guido van Rossum 8 Jolt Productivity Award for Python Category: Languages and Development Tools Runner-up, shared with IntelliJ & RealBasic Category winner: Eclipse SD Magazine & Conference Second time around (last time won was in 2000)

9. March 24, 2005© 2005 Guido van Rossum 9 Python.org Growth Feb 2004 python.org traffic: –793K visits from 421K sites (1.0 TB) Feb 2005 python.org traffic: –1023K visits from 473K sites (1.3 TB) Growth in one year: –visits +29%, originating sites +12%, data +30% –and Feb 2004 had a leap day :-)

10. March 24, 2005© 2005 Guido van Rossum 10 Python Security Response Team Python's first official Vulnerability Alert –Accidental backdoor in SimpleXMLRPCServer –Fixed in Python 2.3.5, 2.4.1 Realized the need for a standard way to handle vulnerabilities Formed Python Security Response Team security@python.org So far, received only a small amount of spam ;-) Burton Group: Python has fewer vulnerabilities than Perl or PHP

11. March 24, 2005© 2005 Guido van Rossum 11 Release Talk It's official: no new features in double-dot releases 2.4.1: rc2 just out; final right after PyCon –sez Anthony Baxter 2.5: next year? 3.0: Who knows? Reminder: slow growth policy

12. March 24, 2005© 2005 Guido van Rossum 12 Python 3000 To be clear: this is the same as Python 3.0 Some progress: collecting ideas in PEP 3000 Py3k is not going to be "second system syndrome done right" (Larry Wall) In particular, not rewriting CPython from scratch More likely, various Py3k features will show up in Python 2.5, 2.6,...; some directly, some with a __future__ import Python 3.0 will be incompatible with Python 2.9 Focus on language + library, not implementation Many VMs competing: Jython, IronPython, Parrot,...

13. March 24, 2005© 2005 Guido van Rossum 13 Improving sum()? sum([1, 2, 3]) returns 6 class C(): def __add__(s, o):... sum([C(), C()]) raise an error But sum([C(), C()], C()) works Why can't sum([C(), C()]) return C()+C()? Lots of attempts to "fix" this; all end up flawed Conclusion: current behavior is right Signature: sum(seq: sequence[T], zero: T = 0) ->T IOW, sum() is already perfect!

14. March 24, 2005© 2005 Guido van Rossum 14 Adding any() and all() def any(seq): for x in seq: if x: return True return False def all(seq): for x in seq: if not x: return False return True Why not return x? –The return type would be surprising either if we fall through the loop or if the sequence is empty Why not anytrue() or anyfalse()? –if any(x < 0 for x in seq): raise ValueError("input<0")

15. March 24, 2005© 2005 Guido van Rossum 15 Killing map(), filter(), reduce() def map(f, seq): return [f(x) for x in seq] def filter(p, seq): return [x for x in seq if p(x)] def reduce(f, seq, zero): r = zero for x in seq: r = f(r, x) return r map() is occasionally clearer, e.g. map(str, seq) filter() is rarely clearer reduce() is usually more obscure –often need to take out pencil & paper to figure it out

16. March 24, 2005© 2005 Guido van Rossum 16 Killing lambda I can smell the next big flame war already :-) Example of bad lambda: map(lambda x: x+42, seq) –Should be [x+42 for x in seq] But: w.setCallback(lambda: self.setText("Booh")) v. def callback(): self.setText("Booh") w.setCallback(callback) Can we add anonymous code blocks? w.setCallback({self.setText("Booh")}) –(That was a joke) It's far from clear what to do here –I haven't had time to follow the discussion on py-dev

17. March 24, 2005© 2005 Guido van Rossum 17 Numeric Needs Requirement: 0-dim array treated as scalar Possible solution: where an int is required (e.g. for indexing a sequence), and something else is given, call its __index__ method to convert it to an int –Avoids the trap that using __int__ would allow floats to be used as indices Requirement: control over zero division behavior Possible solution: make zero division a warning, then use the warning module to control its behavior –Return Inf or NaN when no exception raised –May need to control int and float separately

18. March 24, 2005© 2005 Guido van Rossum 18 Wake Up! Or pretend you're asleep The following may just be a bad dream :-)

19. March 24, 2005© 2005 Guido van Rossum 19 Optional Static Typing NOTE: Nothing's settled yet!!!!!!!!!!!!!!!! Strawman syntax: –def foo(a: int, b: list[int]) -> list[str]:... Strawman semantics: –def foo(a, b): a = __typecheck__(a, int) b = __typecheck__(b, list[int]) r = __original_foo(a, b) return __typecheck__(r, list[str]) –def __typecheck__(x, T): # new builtin if adapt(x, T) is not x: # see PEP 246 raise TypeError(...) return x –__typecheck__ is overridable per module

20. March 24, 2005© 2005 Guido van Rossum 20 Contentious Points The syntax –About 500 people asked whether someone has already proposed using 'x as int' instead of 'x: int' –About 50 people suggested 'int x' –One person proposed 'int(x)' –The ':' is redundant; we could just write def foo(a int, b list[int]) list[str]:... Nobody has pointed this out yet :-) What does list[int] mean, anyway? –Hold that thought... And that's not all...

21. March 24, 2005© 2005 Guido van Rossum 21 Interfaces I am assuming that this will be introduced together with a syntax for interfaces (for example PEP 245) –but the new syntax would not be limited to interfaces Where in the example I wrote list[int], in practice you might be writing sequence[integer] or even iterable[integer] (but not iterator[integer]) Or perhaps list[int] could actually mean the same thing? The one thing we want to avoid at all cost: –people writing list[int] because they think in terms of concrete types, while the right type to use is sequence[integer] or iterable[integer]

22. March 24, 2005© 2005 Guido van Rossum 22 __typecheck__ is a Compromise Note the trick: __typecheck__ passes iff adapt(x, T) returns x itself rather than a wrapper –this allows people to customize type checking by providing identity adapters –for example, adapt([], sequence) should return [] You can override this to use stricter or less strict type checking per module by defining a module- global function named __typecheck__ For example (what the PEP 246 crowd wanted): def __typecheck__(x, T): return adapt(x, T) Perhaps it shouldn't be called __typecheck__?

23. March 24, 2005© 2005 Guido van Rossum 23 Generic types So what does list[int] mean? It's a list of ints, duh! How does this work, in general? It could be Python's syntax for generic types dict[str, int] is a dict with str keys and int values list and dict still work too (same as list[object] etc.) You can define your own parameterized types Contentious strawman syntax: –interface List[T](object): def append(x: T): "yadda yadda" def extend(a: sequence[T]): "..." def __getslice__(i: int, j: int) -> List[T]: "..."

24. March 24, 2005© 2005 Guido van Rossum 24 How to Typecheck Generic Types Ai, there's the rub! def foo(x: list[int]) -> int: bar(x) return x[-1] def bar(x: list): # untyped x.append(snarf()) It would be bad enough to have to verify that every item of x is an int upon entry into foo() It would be even worse to have to do that again after the call to bar(), which might violate the constraint One option: don't check, it's documentation only

25. March 24, 2005© 2005 Guido van Rossum 25 A Psychological Concern What if, despite our best efforts, it becomes a style requirement to use type declarations everywhere? Then we'd have lost! It could happen, given the strong meme that, while dynamic typing is convenient in the short run, static typing is somehow "better" Possible counter-measures: –dynamic signature checking slows down your code –add tools to do type inferencing without declarations –only support type declarations in interfaces –forget the whole thing

26. March 24, 2005© 2005 Guido van Rossum 26 Reminder and Disclaimer If the previous 8 slides felt like a bad dream... Or if they sounded too good to be true... Nothing's settled yet!!!!!!!!!!!!!!!!!!!!!!!!! This is just the beginning (again :-) of a long trip...

27. March 24, 2005© 2005 Guido van Rossum 27 Question Time PS. Stay for the PSF promotional meeting at 10:15