Python 3: The Next Generation +Wesley Chun @wescpy corepython.com - PDF document

Python 3: The Next Generation +Wesley Chun @wescpy corepython.com OSCON, Jul 2012 I Teach 1

I Write ( Core Python books, etc.) I Code (now @ Google) 2

About you and this talk � Assumes some Python knowledge/experience � Will not cover language basics here Today focused on Python 3 � Differences between Python 2 & 3 � Role of remaining Python 2.x releases � Timeline & Transitioning 3

Questions What does it all mean? One � Are all my Python programs going to break? 4

Two � Will I have to rewrite everything? Three � How much time do I have? 5

Four � When is Python 2 going to be EOL'd? Five � Is Python being rewritten completely and will I even recognize it? 6

Six � What are the changes between Python 2 and 3 anyway? Seven � Are migration plans or transition tools available? 7

Eight � Should I start w/Python 2 or Python 3 if I want to learn Python? Nine � Are all Python 2 books obsolete? 8

This talk should be called... � WTF is Python 3? (what) Or maybe... � WTF is Python 3? (why) 9

Or maybe... � WTF is Python 3? (when) Fact or fiction? � Rumors all TRUE... 10

Python 3... � Does exist � There are users � Most of the world still on Python 2 � Some projects have been ported to Python 3 � More projects have started porting to Python 3 Python 2 and Python 3 � Python stands at a crossroads � In transition to next generation � I'm all for version-independence � All about language itself � Not focused on syntax differences 11

But Cannot ignore 3.x backwards- incompatibility Justifying the existence of 3.x � Fix early design flaws � Provide more universal data types � Clean up language and library � Some new features, many small improvements 12

Python 3 Plan � Timeline: 2.x will live on for some time � 2.x and 3.x developed in parallel � Migration tools (i.e., 2to3 , Python 2.6+) � More information in PEPs 3000 and 3100 3.x not backwards-compatible � Is all my Python code going to break? YES � Do I have to rewrite everything? HOPEFULLY NOT � Easy stuff easier, hard stuff harder 13

Backwards-incompatibility means FUD � Causes (negative) buzz in industry � Won't execute most 1.x/2.x code � Will I even recognize Python? � General syntax: same flavor � Easily broken when print becomes a function (vs. stmt) Stability over the years � Backwards-compatibility never been an issue 14

Steadfast determination to preserve compatibility � In 2000, 2.0 ran 1.5.2 software just fine � 2.0a released on same day as 1.6 (Why? ASFAT.) � 2.6 developed at same time as 3.0 (Why? Wait.) The cost � Passes on "sticky" flaws � Passes on deprecated features, unused libraries, etc. � The world is round: Unicode � Hybrid bulk � 2 int types � 2 class/object types � 12 different ways of raising exceptions : 15

Python "Regrets" and "Warts" Python Regrets � http://www.python.org/doc/essays/ppt/regret s/PythonRegrets.pdf 16

Python Warts and others � http://wiki.python.org/moin/PythonWarts Why is Python changing? � Why isn't Python changing? � It usually doesn't! � Always been backwards compatible � Python 3 still recognizable � Not being rewritten/redesigned from scratch 17

Python not a standard (yet) � Backwards-incompatible for the future's sake � Must drop "sticky" flaws and deprecated features � Iterate, improve, evolve, etc. Python 3 breakage � 1st release to deliberately break compatibility � No promise it won't ever happen again � Took 18 years for this first one! � "Backcompat" always top priority except this time � BTW, it's still a high priority 18

Agility � Python promotes agile methods � Continuous iteration, etc. � Interpreter development follows methodology too � 3.0 just a bit larger of a hop Python 2 vs. 3: key differences � What are they? 19

Slight change of syntax � print & exec changed to functions � Single syntax for exceptions Slight change of behavior � True division 1/2 == 0.5 � Iteration upgrades � Iterables everywhere 20

Various Type Updates � Strings: Unicode; bytes/bytearray types � One class type � Updates to integers � Cannot compare mixed types � New "construction" Also general... � Fixes � Deprecation � Improvements 21

print : statement to function � Easiest way to slip up in Python 3 � Especially in interactive interpreter � Need to get used to adding parentheses � Why the change? � As a statement, limits improvements to it print : as a function... � Behavior can be overridden w/keyword parameters � New keyword parameters can be added � Can be replaced if desired, just like any other BIF* � More information in PEP 3105 � (*) BIF = built-in function, FF = factory function 22

Using the "old" `print`: Python (1 and) 2 >>> i = 1 >>> print 'Python' 'is', 'number', i Pythonis number 1 Using the "new" print in 2.6+ >>> from __future__ import print_function >>> print <built-in function print> >>> print('foo', 'bar') foo bar 23

print () in Python 3 � Using the "new" print in 3.0+ >>> i = 1 >>> print('Python' 'is', 'number', i) Pythonis number 1 � (Note: no comma) Strings: Unicode by default � Relief can't come soon enough � People have daily issues w/Unicode vs. ASCII 24

Does the following look familiar? UnicodeEncodeError: 'ascii' codec can't encode character u'\xae' in position 0: ordinal not in range(128) Why does this happen? � Results from non-ASCII characters in valid 8-bit strings � More advice at http://wesc.livejournal.com/1743.html � Also read http://docs.python.org/3.0/howto/unicode.ht ml 25

Unicode vs. ASCII again? Shouldn't use those terms any more � It's text vs. data � Text represented by Unicode... real "strings" � Data == (ASCII, bytes, 8-bit strings, binary data) 26

Changes � str type now bytes (new b literal) � unicode type now str (no more u literal) � basestring deprecated (former base class) � New mutable bytesarray � More information in PEPs 358, 3112, 3137, 3138 Single class type � Python 2.2 � First step taken to unify classes & types � Since then, there have been 2 class types 27

Classic classes vs. New-style classes? Python 2.2-2.7: yes, your ... 28

Python 3 deprecates classic classes � No longer exist � All classes are... � New-style classes � Of the same type � More information in PEPs 252 and 253 "Normal" classes � In typical OOP languages � Classes: types � Instances: objects of those types 29

Problem � Python classic classes not normal � Classes: "class objects" � Instances: "instance objects" No subclasses � Existing Python types can't be derived � Not classes! � "Normal" desire to extend existing types denied � Fake substitutes � UserList , UserDict , etc. 30

Syntactic difference: object class ClassicClass: pass � VS class NewStyleClass(object): pass � Python 3 � Both idioms create same class type Exceptions � In Python (1 and) 2, multiple idioms � For raising � For handling � In Python 3 � Improved, consolidated, less confusing � More info in PEP 3109 and 3110 31

Exception handling � Catching/Handling One Exception except ValueError, e: � Catching/Handling Multiple Exceptions except (ValueError, TypeError), e: � e : exception instance usually has error string Problem: Mistakes easily made � Parentheses required!! � Common pitfall except ValueError, TypeError, e: � Code does not compile ( SyntaxError ) 32

Improving handling � (New) as keyword helps avoid confusion � Parentheses still required New equivalents except ValueError as e: except (ValueError, TypeError) as e: 33

Required in 3.0+ � Available in 2.6+ as transition tool � They accept both � More information in PEP 3110 Consolidated exception throwing/raising � How do I say this? � Python has more than one way to throw exceptions � 12(!) actually if you're counting 34

Most common raise ValueError: raise ValueError, e: � Remember: � "There should be one -- and preferably only one -- obvious way to do it." "New" exception raising idiom � Exceptions formerly strings � Changed to classes in 1.5 � 6 different ways to do this 35

Enabled new idioms raise ValueError() raise ValueError(e) � 6 doubled to 12 Raising in Python 3 � New class instantiation idiom required in 3.0+ � Available in 1.5+ as transition tool :-) � (Changed to new-style classes in 2.5) 36

Updates To Integers *Major � Unification of two integer types � Old long type deprecated � Changing the division operator (/) � Plus new division operator [//] 37

*Minor � New binary literals � Updated octal literals Single integer type � The past: 2 int types � int -- unsigned 32- (or 64-bit) integers � Could overflow � long -- unlimited in size except for VM 38