The State of the Python Union BDFL Keynote @ PyCon – March 24, 2005 Guido van Rossum Elemental...

The State of thePython Union

BDFL Keynote @ PyCon – March 24, 2005

Guido van RossumElemental Security, Inc.

[email protected]@python.org

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


Why my Keynotes Suck


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.htmlcached at: http://purec.binghua.com/Article/Class17/Class22/200412/386.html

• At Elemental I'm now called "professor"


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!


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


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


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)


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 :-)


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

• [email protected]

• So far, received only a small amount of spam ;-)

• Burton Group: Python has fewer vulnerabilities than Perl or PHP


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


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,...


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!


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")


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


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


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


Wake Up!

• Or pretend you're asleep

• The following may just be a bad dream :-)


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


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 writedef 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...


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]


__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__?


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]: "..."


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


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


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...


Question Time

• PS. Stay for the PSF promotional meeting at 10:15

The State of the Python Union BDFL Keynote @ PyCon – March 24, 2005 Guido van Rossum Elemental...

Documents

Transcript of The State of the Python Union BDFL Keynote @ PyCon – March 24, 2005 Guido van Rossum Elemental...