Transcript What's New in Python

The State of the
Python Union
BDFL Keynote @ PyCon – March 24, 2005
Guido van Rossum
Elemental Security, Inc.
[email protected]
[email protected]
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
March 24, 2005
© 2005 Guido van Rossum
2
Why my Keynotes Suck
March 24, 2005
© 2005 Guido van Rossum
3
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"
March 24, 2005
© 2005 Guido van Rossum
4
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!
March 24, 2005
© 2005 Guido van Rossum
5
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
March 24, 2005
© 2005 Guido van Rossum
6
Python's Growing Popularity
• 14% (from 8%) – InfoWorld survey (Sept '04)
– "But the big winner this time around is the objectoriented 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
March 24, 2005
© 2005 Guido van Rossum
7
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)
March 24, 2005
© 2005 Guido van Rossum
8
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 :-)
March 24, 2005
© 2005 Guido van Rossum
9
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
March 24, 2005
© 2005 Guido van Rossum
10
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
March 24, 2005
© 2005 Guido van Rossum
11
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,...
March 24, 2005
© 2005 Guido van Rossum
12
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!
March 24, 2005
© 2005 Guido van Rossum
13
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")
March 24, 2005
© 2005 Guido van Rossum
14
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
March 24, 2005
© 2005 Guido van Rossum
15
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
March 24, 2005
© 2005 Guido van Rossum
16
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
March 24, 2005
© 2005 Guido van Rossum
17
Wake Up!
• Or pretend you're asleep
• The following may just be a bad dream :-)
March 24, 2005
© 2005 Guido van Rossum
18
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
March 24, 2005
© 2005 Guido van Rossum
19
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...
March 24, 2005
© 2005 Guido van Rossum
20
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]
March 24, 2005
© 2005 Guido van Rossum
21
__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 moduleglobal 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__?
March 24, 2005
© 2005 Guido van Rossum
22
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]: "..."
March 24, 2005
© 2005 Guido van Rossum
23
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
March 24, 2005
© 2005 Guido van Rossum
24
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
March 24, 2005
© 2005 Guido van Rossum
25
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...
March 24, 2005
© 2005 Guido van Rossum
26
Question Time
• PS. Stay for the PSF promotional meeting at 10:15
March 24, 2005
© 2005 Guido van Rossum
27