Python Evolution 2.4, 2.5, 2.6, 3.0 by Myroslav Opyr, CTO © Quintagroup 2008
May 10, 2015
Python Evolution2.4, 2.5, 2.6, 3.0by Myroslav Opyr, CTO
© Quintagroup 2008
Contents
• Python 2.x featureso 2.4o 2.5o 2.6
• Why Python 3k?• Distribution as competitive benefit• References
Python 2.4 features
• built-in sets (PEP 218)• generator expressions (PEP 289)• new subprocess module (PEP 324)• function/method decorators (PEP 318)
Python 2.5 features
• abstract syntax tree (AST)• 'with' statement (PEP 343)• absolute/relative imports (PEP 328)• distutils gained dependency info (PEP 314)• wsgiref package (PEP 333)• coroutines (PEP 342)
Non-features• PyPI accepts uploads• Continuous Integration with buildbot
Python 2.6 features
• no more string exceptions• The "bytes" Object (PEP 358)• warnings for features to be removed in P3k• multiprocessing (PEP 371)• ast module• setuptools module• 2to3
Non-features• Python bugtracker moved to roundup
Questions?
pause...
Python 3k/3000/3.0
• Incompatible changeso What Python 3.0 won't beo What Python 3.0 will be
• Release Plan• Migration process
o 2to3
Python 3.0. Evolution philosophy
Joel on Software: Things You Should Never Do, Part I: Netscape was waiting so long between releases by making the
single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch.
http://www.joelonsoftware.com/articles/fog0000000069.html
What Python 3.0 won't be
PEP-3099 highlights:• Python 3000 will not be case-insensitive• Python 3000 will not be a rewrite from scratch• self will not become implicit• lambda will not be renamed• No braces (from __future__ import braces)• Iterating over a dictionary will continue to yield the keys• The interpreter prompt (>>>) will not change. It gives Guido
warm fuzzy feelings
What Python 3.0 will be
PEP-3000 Python 3.0 development guidelines:• PEP Numbering• Timeline• Compatibility and Transition• Implementation Language
PEP-3100 Python 3.0 implementation "reduce feature duplication by removing old ways of doing things.
A general principle of the design will be that one obvious way of doing something is enough."
Python 3.0. Core language
• True division becomes default behavior• exec as a statement is not worth it -- make it a function• Add optional declarations for static typing (annotations)• Support only new-style classes; classic classes will be gone• Replace print by a function• The softspace attribute of files goes away.• Use except E1, E2, E3 as err: if you want the error variable.• None becomes a keyword; also True and False• as becomes a keyword• Comparisons other than == and != between disparate types will
raise an exception unless explicitly supported by the type
Python 3.0. Core language (cont.)
• floats will not be acceptable as arguments in place of ints for operations where floats are inadvertantly accepted
• Remove from ... import * at function scope.• Imports
o Imports will be absolute by default.o Relative imports must be explicitly specified.
• Some expressions will require parentheses that didn't in 2.x: o List comprehensions will require parentheses around the
iterables. This will make list comprehensions more similar to generator comprehensions. [x for x in 1, 2] will need to be: [x for x in (1, 2)]
• Set literals and comprehensions. {x} means set([x]); {x, y} means set([x, y]).
Python 3.0. Core language (cont.)
To be removed:• String exceptions: use instances of an Exception class• raise Exception, "message": use raise Exception("message")• `x`: use repr(x)• The <> operator: use != instead• Drop unbound methods• __getslice__, __setslice__, __delslice__; remove slice opcodes
and use slice objects.• __oct__, __hex__: use __index__ in oct() and hex() instead.• __methods__ and __members__
Python 3.0. Atomic Types
• Remove distinction between int and long types; 'long' built-in type and literals with 'L' or 'l' suffix disappear
• Make all strings be Unicode, and have a separate bytes() type. The new string type will be called 'str'. See PEP 3137.
• Return iterable views instead of lists where appropriate for atomic type methods (e.g. dict.keys(), dict.values(), dict.items(), etc.); iter* methods will be removed.
To be removed:• file.xreadlines() method• dict.has_key() method; use in operator• list.sort() and builtin.sorted() methods: eliminate cmp parameter
Python 3.0. Built-in Namespace
• Make built-ins return an iterator where appropriate (e.g. range(), zip(), map(), filter(), etc.)
• Remove input() and rename raw_input() to input(). If you need the old input(), use eval(input()).
• Introduce trunc(), which would call the __trunc__() method on its argument; suggested use is for objects like float where calling __int__() has data loss, but an integral representation is still desired
• Exception hierarchy changes• Add a bin() function for a binary representation of integers
Python 3.0. Built-in Namespace (cont.)
To be removed:• apply(): use f(*args, **kw) instead• buffer(): must die (use a bytes() type instead)• callable(): just use hasattr(x, '__call__')• compile(): put in sys• coerce(): no longer needed• execfile(), reload(): use exec()• intern(): put in sys• reduce(): put in functools, a loop is more readable most of the
times• xrange(): use range()• StandardError: this is a relic from the original exception hierarchy;
subclass Exception instead.
Python 3.0. Release Plan
PEP-361: Python 2.6 and 3.0 are lock-stepped (the same procedure was used for 1.6 and 2.0):• Feb 29 2008: Python 2.6a1 and 3.0a3 are released• Apr 02 2008: Python 2.6a2 and 3.0a4 are released• May 08 2008: Python 2.6a3 and 3.0a5 are released• Jun 18 2008: Python 2.6b1 and 3.0b1 are released• Jul 02 2008: Python 2.6b2 and 3.0b2 planned• Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned• Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned• Sep 03 2008: Python 2.6 and 3.0 final
Python 3.0. Migration
Python 3.0 will break backwards compatibility with Python 2.x.There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset.Python 2.6 will support forward compatibility in the following two ways:• It will support a "Py3k warnings mode" which will warn dynamically (i.e.
at runtime) about features that will stop working in Python 3.0, e.g. assuming that range() returns a list.
• It will contain backported versions of many Py3k features, either enabled through __future__ statements or simply by allowing old and new syntax to be used side-by-side (if the new syntax would be a syntax error in 2.x).
Python 3.0. Migration (cont.)
The recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously is as follows:1. You should have excellent unit tests with close to full coverage.– Port your project to Python 2.6.– Turn on the Py3k warnings mode.– Test and edit until no warnings remain.– Use the 2to3 tool to convert this source code to 3.0 syntax. Do not manually edit the
output!– Test the converted source code under 3.0.– If problems are found, make corrections to the 2.6 version of the source code and go
back to step 3.– When it's time to release, release separate 2.6 and 3.0 tarballs (or whatever archive
form you use for releases).It is recommended not to edit the 3.0 source code until you are ready to reduce 2.6 support to pure maintenance (i.e. the moment when you would normally move the 2.6 code to a maintenance branch anyway).
Python 3.0. Questions?
pause...
Distributing Python code
• Why distribution is important?• distutils• setuptools• easy_install• virtualenv• Private PyPI
Why distribution is important?
• Simpler installation makes Python software reusable andmore accessible
• More users• More pressure to package developers• Better distributions
o more meta-datao more documentationo more testso more platforms
• "CheeseCake" rating system (better package kwalitee)
distutils
For end-users: python setup.py install
For developers: python setup.py sdist
For packagers: python setup.py bdist
Since Python-2.5, you can host your packages directly on PyPI python setup.py upload
setuptools
• Automatically find/download/install/upgrade dependencies at build time using the EasyInstall tool, which supports downloading via HTTP, FTP, Subversion, and SourceForge, and automatically scans web pages linked from PyPI to find download links. (It's the closest thing to CPAN currently available for Python.)
easy_install grockproject
• Create Python Eggs - a single-file importable distribution format python setup.py bdist_egg
setuptools (cont.)
• Command aliases - create project-specific, per-user, or site-wide shortcut names for commonly used commands and options
• PyPI upload support - upload your source distributions and eggs to PyPI• Deploy your project in "development mode", such that it's available on sys.path, yet
can still be edited directly from its source checkout.• Easily extend the distutils with new commands or setup() arguments, and
distribute/reuse your extensions for multiple projects, without copying code.• Create extensible applications and frameworks that automatically discover
extensions, using simple "entry points" declared in a project's setup script.
easy_install
easy_install SQLObject
easy_install -f http://pythonpaste.org/package_index.html SQLObject
easy_install http://example.com/path/to/MyPackage-1.2.3.tgz
easy_install /my_downloads/OtherPackage-3.2.1-py2.3.egg
easy_install --upgrade PyProtocols
easy_install .
easy_install --editable --build-directory ~/projects SQLObject
virtualenv
virtualenv is a tool to create isolated Python environments. The basic usage is: $ python virtualenv.py ENV
This creates ENV/lib/python2.4/site-packages , where anylibraries you install will go. It also creates ENV/bin/python,which is a Python interpreter that uses this environment.
Allows bootstrap scripts that prepare environment.
Alternatives:• workingenv• virtual-python• zc.buildout
Private PyPI
Folder...with eggs exposed (and password-protected) via Apache. Works with easy_install, requires "manual" uploading to folder, can be as simple as copy to shared folder
haufe.eggservergrok-powered solution. Recently upload support added. No dedicated security model (everyone is trusted and allowed to upload packages).Plone Software Center 1.5Plone product. Support upload, categorization, security. Has buildout.
Questions?
References
• http://www.python.org/download/releases/2.4/highlights/• http://www.python.org/download/releases/2.5/highlights/• http://www.joelonsoftware.com/articles/fog0000000069.html• http://www.python.org/dev/peps/pep-0361/• http://www.python.org/dev/peps/pep-3000/• http://www.python.org/dev/peps/pep-3099/• http://www.python.org/dev/peps/pep-3100/• http://www.python.org/download/releases/3.0/• http://mail.python.org/pipermail/python-dev/2006-April/064145.html• http://www.python.org/doc/current/inst/inst.html• http://docs.python.org/dist/dist.html• http://pypi.python.org/pypi/setuptools/• http://peak.telecommunity.com/DevCenter/setuptools• http://pypi.python.org/pypi/virtualenv• http://pypi.python.org/pypi/haufe.eggserver/• http://tarekziade.wordpress.com/2008/03/20/how-to-run-your-own-private-pypi-cheeseshop-se
rver/
Thanks
http://sites.google.com/a/quintagroup.com/techtalks/Topics/python-evolution